gnupic: Thread: SDCC

I've been writing a few tests for sdcc, and then bothering Scott
about those that don't work. As I did that I got curious about
how the generated code compared to other compilers.

I tried my "alfa.c" on the pic compilers I could find, and then
measured execution time using gpsim. All compilers are demo versions
downloaded from the web. It may be that the regular versions are better,
but that seems strange.

It may not say much, alfa.c perhaps is not the most 'average' program.

accumulated cycles:
	sdcc    picc    picc -O -Zg9    CCSC    sdcc uchar      mpc
init	2       0x145   0x143           ?                       9
t1	0xc7    0x24a   0x214           0x76    0x5e            ?
t2	0x708   0xbae   0x96b           0x46c   0x36c           0x9b3
t3	0x26303 0x3d381 0x2e3cd         0x1f7f6 0x14585         0x3fbbe

init is the number of cycles before the call to test1().
t1 is the number of cycles used from start to after test1 is finished.
t2 is the numb......from start to after test2 is finished.
t3 is the........to after test3 is finished.


cycles used per test:
	sdcc	picc	picc -O -Gz	CCSC	sdcc uchar	mpc
t1	0xc5	0x105	0xd1		0x76-	0x5e-		?
t2	0x641	0x964	0x757		0x3f6	0x30e		0x9aa
t3	0x25bfb	0x3c7d3	0x2da62		0x1fe8a	0x14219		0x3f20b


sdcc does really well. The numbers for CCSC come from the fact that it
defines 'int' as an 8-bit number. So I tried alfa.c using 8-bit vars
and sdcc, and it's smoked. I don't know about the mpc demo, perhaps it's
an old version.

And as for program size:
		initialization	program		total
sdcc                                            252
picc            58              285             343
ccsc                                            161
sdccchar                                        139
mpc                                             239

mpc beats sdcc here, it seems it's optimized for space. I wonder
how it did so badly in execution time. 

It's not yet a fair comparasion since there is a lot of functionality
missing in sdcc, but it shows promise.

I wanted to measure register usage too, but I found that hard to do.
(gpsim could use a coverage feature. )

I wonder if I missed some compiler flags for some program, I really
looked but I could have missed some. If so, or if you know of a better
compiler, then let me know.

alfa.c and the .hex files can be found at http://rfg.myip.org/sdcc/test/

 / Ralf

Hi, Ralf:

Which version of SDCC did you try in your tests.  I just 
downloaded SDCC (v2.3.0 Sept 20 20001) from the web site
and found it doesn't work for PIC devices.

Thanks!

- Mengjin Su -
Agilent Tech.


-----Original Message-----
From: Ralf Forsberg ####@####.####
Sent: Tuesday, November 13, 2001 3:26 AM
To: ####@####.####
Subject: SDCC


I've been writing a few tests for sdcc, and then bothering Scott
about those that don't work. As I did that I got curious about
how the generated code compared to other compilers.

I tried my "alfa.c" on the pic compilers I could find, and then
measured execution time using gpsim. All compilers are demo versions
downloaded from the web. It may be that the regular versions are better,
but that seems strange.

It may not say much, alfa.c perhaps is not the most 'average' program.

accumulated cycles:
	sdcc    picc    picc -O -Zg9    CCSC    sdcc uchar      mpc
init	2       0x145   0x143           ?                       9
t1	0xc7    0x24a   0x214           0x76    0x5e            ?
t2	0x708   0xbae   0x96b           0x46c   0x36c           0x9b3
t3	0x26303 0x3d381 0x2e3cd         0x1f7f6 0x14585         0x3fbbe

init is the number of cycles before the call to test1().
t1 is the number of cycles used from start to after test1 is finished.
t2 is the numb......from start to after test2 is finished.
t3 is the........to after test3 is finished.


cycles used per test:
	sdcc	picc	picc -O -Gz	CCSC	sdcc uchar	mpc
t1	0xc5	0x105	0xd1		0x76-	0x5e-		?
t2	0x641	0x964	0x757		0x3f6	0x30e		0x9aa
t3	0x25bfb	0x3c7d3	0x2da62		0x1fe8a	0x14219		0x3f20b


sdcc does really well. The numbers for CCSC come from the fact that it
defines 'int' as an 8-bit number. So I tried alfa.c using 8-bit vars
and sdcc, and it's smoked. I don't know about the mpc demo, perhaps it's
an old version.

And as for program size:
		initialization	program		total
sdcc                                            252
picc            58              285             343
ccsc                                            161
sdccchar                                        139
mpc                                             239

mpc beats sdcc here, it seems it's optimized for space. I wonder
how it did so badly in execution time. 

It's not yet a fair comparasion since there is a lot of functionality
missing in sdcc, but it shows promise.

I wanted to measure register usage too, but I found that hard to do.
(gpsim could use a coverage feature. )

I wonder if I missed some compiler flags for some program, I really
looked but I could have missed some. If so, or if you know of a better
compiler, then let me know.

alfa.c and the .hex files can be found at http://rfg.myip.org/sdcc/test/

 / Ralf




---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####

On Tue, Nov 13, 2001 at 10:07:12AM -0700, ####@####.#### wrote:
> Hi, Ralf:
> 
> Which version of SDCC did you try in your tests.  I just 
> downloaded SDCC (v2.3.0 Sept 20 20001) from the web site
> and found it doesn't work for PIC devices.

The pic port changes rapidly, I used yesterdays CVS version.

 / Ralf

On Tue, 13 Nov 2001 22:26, Ralf Forsberg wrote:
> I've been writing a few tests for sdcc, and then bothering Scott
> about those that don't work. As I did that I got curious about
> how the generated code compared to other compilers.
> 
> I tried my "alfa.c" on the pic compilers I could find, and then
> measured execution time using gpsim. All compilers are demo versions
> downloaded from the web. It may be that the regular versions are better,
> but that seems strange.
> 
> It may not say much, alfa.c perhaps is not the most 'average' program.
> 
> accumulated cycles:
> 	sdcc    picc    picc -O -Zg9    CCSC    sdcc uchar      mpc
> init	2       0x145   0x143           ?                       9
> t1	0xc7    0x24a   0x214           0x76    0x5e            ?
> t2	0x708   0xbae   0x96b           0x46c   0x36c           0x9b3
> t3	0x26303 0x3d381 0x2e3cd         0x1f7f6 0x14585         0x3fbbe
> 

Ok, here's my thoughts. I would be VERY VERY VERY surprised if sdcc could 
beat all those compilers this well with Scott still developing it.

here's my thoughts. Check all the hex. files to see if they work.. not if 
they simply execute to the end. 

Specifically Ralf could supply results of the execution to prove that indeed 
singed math was used (big over head here) and that all compilers were 
actually doing 16 bit math (bigger overheads obviously)... and even look to 
see if in-line functions were ever employed. 
This is not an error, but might explain how a compiler is winning - ie. it's 
not really optimising the maths, just killing little bits of code around the 
place..

thanks

Matt

P.S, on a re-read of my english skills.. I think I could have written 
'signed' and not 'singed'.. I have a suspicion that PICs are not compatible 
with burning maths.
[ 2001 ]

> 
> Ok, here's my thoughts. I would be VERY VERY VERY surprised if sdcc could 
> beat all those compilers this well with Scott still developing it.
> 

sorry just noticed that my comment could be read as insulting. I meant 
'withthe compiler still under development of which Scott is in charge .. NOT 
-> because Scott is developing it. it will never beat good compilers..

phew?!?!

sorry if taken wrong way.
apologies.

matt
[ 2001 ]

On Wed, 14 Nov 2001, matt wrote:

> On Tue, 13 Nov 2001 22:26, Ralf Forsberg wrote:
> > I've been writing a few tests for sdcc, and then bothering Scott
> > about those that don't work. As I did that I got curious about
> > how the generated code compared to other compilers.
> >
> > I tried my "alfa.c" on the pic compilers I could find, and then
> > measured execution time using gpsim. All compilers are demo versions
> > downloaded from the web. It may be that the regular versions are better,
> > but that seems strange.
> >
> > It may not say much, alfa.c perhaps is not the most 'average' program.
> >
> > accumulated cycles:
> > 	sdcc    picc    picc -O -Zg9    CCSC    sdcc uchar      mpc
> > init	2       0x145   0x143           ?                       9
> > t1	0xc7    0x24a   0x214           0x76    0x5e            ?
> > t2	0x708   0xbae   0x96b           0x46c   0x36c           0x9b3
> > t3	0x26303 0x3d381 0x2e3cd         0x1f7f6 0x14585         0x3fbbe
> >
>
> Ok, here's my thoughts. I would be VERY VERY VERY surprised if sdcc could
> beat all those compilers this well with Scott still developing it.

Matt,

There's no reason for suprise, I've seen the code SDCC's produced.

> here's my thoughts. Check all the hex. files to see if they work.. not if
> they simply execute to the end.

The code is accurate too, but you're implication is partially correct.
The PIC port of SDCC is by no means complete. The parts that are complete
are fairly well optimized. Look here to get an idea what SDCC is capable
of:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sdcc/sdcc/src/regression/

These are regression tests I've created to verify SDCC's correctness. I
haven't run these tests against any of the other compilers. I know that
SDCC passes on all of them, however.

>
> Specifically Ralf could supply results of the execution to prove that indeed
> singed math was used (big over head here) and that all compilers were
> actually doing 16 bit math (bigger overheads obviously)... and even look to
> see if in-line functions were ever employed.
> This is not an error, but might explain how a compiler is winning - ie. it's
> not really optimising the maths, just killing little bits of code around the
> place..

Again, within the scope of this specific test, SDCC is the fastest
executing. Although I wouldn't be surprised if MPC or Hi-Tech can be
supplied with the proper command line options to improve their execution
and even beat SDCC. C2C (not tested) and CCSC, otoh, probably don't have a
chance.

----

I still have *, /, and % to complete before the basic operation of the PIC
port is done. At this point, SDCC will be capable of compiling single .c
files to produce an excutable. This is somewhat like C2C's limitation, but
will probably be useful for many applications. I expect these to be done
within 4 weeks. After that I'll start performing more rigorous tests that
involve pointers, structures, etc. A solid beta should be ready around
February or March '01.

Also going on unnoticed is Craig's linker development. I suspect that
Craig will have something ready about the time I need it - not to put
words in his mouth though. I'll be porting a portion of SDCC to the
linker. The linker will be an optimizing one. In fact, properly
constructed assembly will be optimizable too! By properly constructed, I
don't mean inefficiently written :). Instead, I mean using some new gpasm
pragmas that will be added. So things like register overlaying, function
inlining, peep hole optimizing, tail optimizing, etc. will be introduced
to the linker.

Scott

Scott Dattalo mused:
>>A solid beta should be ready around February or March '01.

Um... methinks that this is impossible, unless you've been holding out on
the GNUPIC community for about 9 months ;)

-Randy Glenn

Measure twice, cut once, curse, discard.
Repeat.=================================================
    ####@####.#### - ####@####.####
           http://picxpert.dyndns.org
    Not that the site works yet, of course...
=================================================

-----Original Message-----
From: Scott Dattalo ####@####.####
Sent: Tuesday, November 13, 2001 10:20 PM
Cc: ####@####.####
Subject: Re: SDCC


On Wed, 14 Nov 2001, matt wrote:

> On Tue, 13 Nov 2001 22:26, Ralf Forsberg wrote:
> > I've been writing a few tests for sdcc, and then bothering Scott
> > about those that don't work. As I did that I got curious about
> > how the generated code compared to other compilers.
> >
> > I tried my "alfa.c" on the pic compilers I could find, and then
> > measured execution time using gpsim. All compilers are demo versions
> > downloaded from the web. It may be that the regular versions are better,
> > but that seems strange.
> >
> > It may not say much, alfa.c perhaps is not the most 'average' program.
> >
> > accumulated cycles:
> > 	sdcc    picc    picc -O -Zg9    CCSC    sdcc uchar      mpc
> > init	2       0x145   0x143           ?                       9
> > t1	0xc7    0x24a   0x214           0x76    0x5e            ?
> > t2	0x708   0xbae   0x96b           0x46c   0x36c           0x9b3
> > t3	0x26303 0x3d381 0x2e3cd         0x1f7f6 0x14585         0x3fbbe
> >
>
> Ok, here's my thoughts. I would be VERY VERY VERY surprised if sdcc could
> beat all those compilers this well with Scott still developing it.

Matt,

There's no reason for suprise, I've seen the code SDCC's produced.

> here's my thoughts. Check all the hex. files to see if they work.. not if
> they simply execute to the end.

The code is accurate too, but you're implication is partially correct.
The PIC port of SDCC is by no means complete. The parts that are complete
are fairly well optimized. Look here to get an idea what SDCC is capable
of:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sdcc/sdcc/src/regression/

These are regression tests I've created to verify SDCC's correctness. I
haven't run these tests against any of the other compilers. I know that
SDCC passes on all of them, however.

>
> Specifically Ralf could supply results of the execution to prove that
indeed
> singed math was used (big over head here) and that all compilers were
> actually doing 16 bit math (bigger overheads obviously)... and even look
to
> see if in-line functions were ever employed.
> This is not an error, but might explain how a compiler is winning - ie.
it's
> not really optimising the maths, just killing little bits of code around
the
> place..

Again, within the scope of this specific test, SDCC is the fastest
executing. Although I wouldn't be surprised if MPC or Hi-Tech can be
supplied with the proper command line options to improve their execution
and even beat SDCC. C2C (not tested) and CCSC, otoh, probably don't have a
chance.

----

I still have *, /, and % to complete before the basic operation of the PIC
port is done. At this point, SDCC will be capable of compiling single .c
files to produce an excutable. This is somewhat like C2C's limitation, but
will probably be useful for many applications. I expect these to be done
within 4 weeks. After that I'll start performing more rigorous tests that
involve pointers, structures, etc. A solid beta should be ready around
February or March '01.

Also going on unnoticed is Craig's linker development. I suspect that
Craig will have something ready about the time I need it - not to put
words in his mouth though. I'll be porting a portion of SDCC to the
linker. The linker will be an optimizing one. In fact, properly
constructed assembly will be optimizable too! By properly constructed, I
don't mean inefficiently written :). Instead, I mean using some new gpasm
pragmas that will be added. So things like register overlaying, function
inlining, peep hole optimizing, tail optimizing, etc. will be introduced
to the linker.

Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

On Wed, Nov 14, 2001 at 12:27:05PM +1100, matt wrote:
> On Tue, 13 Nov 2001 22:26, Ralf Forsberg wrote:
> > I tried my "alfa.c" on the pic compilers I could find, and then
> > measured execution time using gpsim. All compilers are demo versions
> > downloaded from the web. It may be that the regular versions are better,
> > but that seems strange.
> > 
> > It may not say much, alfa.c perhaps is not the most 'average' program.
> > 
> > accumulated cycles:
> > 	sdcc    picc    picc -O -Zg9    CCSC    sdcc uchar      mpc
> > init	2       0x145   0x143           ?                       9
> > t1	0xc7    0x24a   0x214           0x76    0x5e            ?
> > t2	0x708   0xbae   0x96b           0x46c   0x36c           0x9b3
> > t3	0x26303 0x3d381 0x2e3cd         0x1f7f6 0x14585         0x3fbbe
> > 
> 
> Ok, here's my thoughts. I would be VERY VERY VERY surprised if sdcc could 
> beat all those compilers this well with Scott still developing it.
> 
> here's my thoughts. Check all the hex. files to see if they work.. not if 
> they simply execute to the end. 

I checked that it works, in the sense that the test functions calculated 
the magic values.

> 
> Specifically Ralf could supply results of the execution to prove that indeed 
> singed math was used (big over head here)

I have put the sdcc generated .asm file at http://rfg.myip.org/sdcc/test

I'll try unsigned math too, tomorrow.

>and even look to 
> see if in-line functions were ever employed. 

IIRC ccsc was the only one using inline functions.


No one would be happier than scott if you find bugs in the code. As I said
in my first mail, it's not yet a fair comparasion since many things don't
work yet.

 / Ralf

On Wed, Nov 14, 2001 at 12:27:05PM +1100, matt wrote:
> On Tue, 13 Nov 2001 22:26, Ralf Forsberg wrote:
> > I've been writing a few tests for sdcc, and then bothering Scott
> > about those that don't work. As I did that I got curious about
> > how the generated code compared to other compilers.
> > 
> > I tried my "alfa.c" on the pic compilers I could find, and then
> > measured execution time using gpsim. All compilers are demo versions
> > downloaded from the web. It may be that the regular versions are better,
> > but that seems strange.
> > 
> > It may not say much, alfa.c perhaps is not the most 'average' program.
> > 
> > accumulated cycles:
> > 	sdcc    picc    picc -O -Zg9    CCSC    sdcc uchar      mpc
> > init	2       0x145   0x143           ?                       9
> > t1	0xc7    0x24a   0x214           0x76    0x5e            ?
> > t2	0x708   0xbae   0x96b           0x46c   0x36c           0x9b3
> > t3	0x26303 0x3d381 0x2e3cd         0x1f7f6 0x14585         0x3fbbe
> > 

Also, those numbers are misleading, since they count cycles from reset.
The "cycles per test" is better.§


> Ok, here's my thoughts. I would be VERY VERY VERY surprised if sdcc could 
> beat all those compilers this well with Scott still developing it.
> 

 / Ralf

Hello Listers,

I have just downloaded and installed sdcc from the sdcc website.  I remember
about 1 month ago, Scott supplied some information about how to procure the
latest pic files from sourceforge.  Unfortunately I have lost this.

Any help would be appreciated

Regards

John
####################################
#                                  #
# PLEASE DO NOT REPLY DIRECTLY TO  #
#       THIS EMAIL ADDRESS         #
#                                  #
# Send replies to:                 #
#     ####@####.####          #
####################################