[<<] [<] Page 1 of 2 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
SDCC
From: Ralf Forsberg ####@####.#### Date: 13 Nov 2001 11:28:00 -0000 Message-Id: <20011113122622.A488@home.se> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: SDCC
From: ####@####.#### Date: 13 Nov 2001 17:07:36 -0000 Message-Id: <9F8400020EC5D311AF62009027C3961603226B3E@axcs09.cos.agilent.com> 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: ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC
From: Ralf Forsberg ####@####.#### Date: 13 Nov 2001 17:44:33 -0000 Message-Id: <20011113184407.B723@home.se> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC
From: matt ####@####.#### Date: 14 Nov 2001 01:27:15 -0000 Message-Id: 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 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC
From: matt ####@####.#### Date: 14 Nov 2001 01:32:13 -0000 Message-Id: > > 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 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC
From: Scott Dattalo ####@####.#### Date: 14 Nov 2001 03:19:42 -0000 Message-Id: <Pine.LNX.4.33.0111131851070.27761-100000@ruckus.brouhaha.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: SDCC
From: "Randy Glenn" ####@####.#### Date: 14 Nov 2001 03:44:40 -0000 Message-Id: <NDBBLGEHGLHAOEKCDCNDCEFOEOAA.PICxpert@yahoo.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC
From: Ralf Forsberg ####@####.#### Date: 14 Nov 2001 06:23:14 -0000 Message-Id: <20011114072253.A19924@home.se> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: SDCC
From: Ralf Forsberg ####@####.#### Date: 14 Nov 2001 07:05:19 -0000 Message-Id: <20011114080454.A21047@home.se> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
sdcc
From: John Duncan ####@####.#### Date: 29 Jun 2002 09:35:10 -0000 Message-Id: <Pine.A41.4.05.10206281549580.15016-100000@alto1.qld.bom.gov.au> 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: # # ####@####.#### # #################################### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 2 [>] [>>] |