At 10:27 4/11/98 PST, you wrote:
>Dear Sir(s),
>
>I'm dealing with a compiler C17 V2.1 demo crash problem when
>I try to compile the Dhrystone sources attached. I'm tryng to do
>a benchmark on code size generated and performance when
>compared to other processors/compilers (80251/C251 from Keil
>and 68HC08/C08 from Cosmic). I use the Visual C++ 1.5 from
>Microsoft and the C251 from Keil to compile all of then and I get
>the code, despite the warning messages generated.
>I'll appreciate very much any help.
>
>Here are the data I have untill now using the C17 V2.1 demo:
>1. Source DHRY.C: I get the following message:
>C:\PROGS\MPLAB\mcc\Examples\DHRY>c17demo /w1 /Ms /dNOENUM /p=17C756 dhry.c
>MPLAB-C17 v2.10 (demo)
>Copyright 1997, 1998 Microchip Technology Inc.
>The instruction at 0x0043bc99 referenced memory at 0xffffffff.
>The memory could not be read.
>
>2. DHRY1.C: I get to many compiler errors.
>
>3. DHRY2.C: It's DHRY1.C, trying to remive the errors. I get the message:
>C:\PROGS\MPLAB\mcc\Examples\DHRY>c17demo /w1 /Ms /dNOENUM /p=17C756 dhry2.c
>MPLAB-C17 v2.10 (demo)
>Copyright 1997, 1998 Microchip Technology Inc.
>Stack Overflow!
>
>4. DHRY3.C: It's DHRY2.C. I was able to compile them WITH the functions
>Proc1 e Proc3 commented (see  "/// Stack Overflow Problem!!!" comment
>in the file FUNCS.C), so the stack overflow compiler problem is inside
>this functions.
>
>Hopping that someone help me,
>Best Regards,
>Paulo Sa'
>
>E-Mail: paulosa@meta.com.br
>Meta Telecomunicacoes S/A
>Fone/Fax: 55-51-337-1977 Ext: 250
>
>Attachment Converted: C:\EUDORA\ATTACH\DHRY.zip
>

Humm, seems that your trying to make it fit into a processor with not enough
memory, could you please supply the switches used (I don't want to have to
wade through the source code, sorry).

Dhrystone testing, bit unfair wouldn't you say? All are very different, the
poor old 6805 will have a fit with that, closely followed by the 8051
(Unless it is running at 33MHz). Often it is not the size of the code that
matters but the quality. Note that the Keil (Unless you use the large memory
model) will be a call graph type, where as the 6805 will nominally only use
a call graph.

As far as code size, the 6805 will be the largest, then the Z8 then the 8051
then the PIC. Often you will find that what make the code small is a smart
linker or good libraries that does not bring in the entire file. Try a
"toupper ()" on all of them and have a look at the amount of RAM used! Then
use the old "printf ()" See the difference then.

But I may be preaching to the converted, it is just that in the world of
embedded Dhrystones don't really mean much, but that's a personal opinion.


Dennis