i use the iar (not necessary my will) recently i "compressed" a code from 1400 to less than 1000 and is room for more all this without writting in asm (allmost) the trick is to know asm and read what the compiler produce so: 1. you can optimize the c 2. you can write in asm bouth ways start mastering assembler (i have the filling i repeat somebody, if so please excuse me) ----- rattencremesuppe <tricknology@tric...> wrote: Hi, I'm about to start my first MSP430 project. I'll have to write a fairly complex firmware but can only use the 60K on-chip flash. I've used the GCC in some Linux projects and while it's a standard and a portable solution, I suspect that commercial compilers may outperform it w.r.t smaller code size of compiled C-code. What compilers do you use, when code size is crucial? Regards, Patrick --------------------------------- Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers!
which C-compiler produces the smallest code size?
Started by ●September 14, 2004
Reply by ●September 15, 20042004-09-15
Reply by ●September 15, 20042004-09-15
Paul Curtis wrote: > Shaun, > > >>Hi Patrick, >> >>I have done a comparison between GCC 3.2.3 and the IAR >>compiler that was packaged with my FET kit. (I don't know >>what version) >> >>GCC produced significantly smaller code, as the IAR compiler >>pulled in library functions to handle shift operations and >>simple integer maths. > > > Actually, if you use some real benchmarks such as MiBench or the TI > benchmarksm GCC produces the worst code of the lot... In one case, on > an MSP430F149, it won't fit an application into flash, whereas all other > compilers do. This is contrary to my experience. Can you give numbers? > What does that say? Just that benchmarks are very subjective. However, > GCC produces code far inferior to IAR, IMO. The float library isn't optimized for MSP430 and thus not very small, but the compiled code usually is as least as good as IAR's.
Reply by ●September 15, 20042004-09-15
Hi,
> i generally aggree but if the code has dozenz of
floats gcc produces
bigger code.
I think that's not an issue for me, because I always use fixed-point
integers.
Regards,
Patrick
Reply by ●September 15, 20042004-09-15
Hi Andreas, > > Actually, if you use some real benchmarks such as MiBench or the TI > > benchmarksm GCC produces the worst code of the lot... In > one case, on > > an MSP430F149, it won't fit an application into flash, > whereas all other > > compilers do. > > This is contrary to my experience. Can you give numbers? Ok, let's put this "GCC produces the smallest code and is a good compiler" myth to bed, shall we? At http://www.rowley.co.uk/msp430/mibench.zip is the Susan benchmark from MiBench at http://www.eecs.umich.edu/mibench/. MiBench is an image processing benchmark and uses fixed-point math almost exclusively. I compiled this for MSP430 using GCC, CrossWorks, and EW430. GCC IAR RAL EW430 XWorks ------ ------ ------ Code size: 29,998 16,732 16,198 Const ssize: 15,286 15,801 15,770 ------ ------ ------ 45,284 32,553 31,968 The interesting thing here is CODE SIZE not CONST SIZE (which is a fixed-size array). The code produced by CrossWorks and by IAR is half the size of GCC. HALF THE SIZE! 30K vs 16K. ...and GCC produces small code... So, is GCC a good compiler? No, in this case, far from it. If someboduy can get anywhere near the code size of EW430 or CrossWorks using GCC, just let me know what settings to use and I'll post again, or you can post. Even considering a non-optimized floating point library, it doesn't take up 14K of code. GCC Environment: I used -O1 which generates the smallest code, and compiled for an F149 with multiplier; I had to supply dummy exp and sqrt functions for GCC, I don't know how to get them linked in (-lm didn't help). So, if sqrt and exp *were* added, the GCC sizes would be even worse... Comments? -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors
Reply by ●September 15, 20042004-09-15
And to say... > I compiled this for MSP430 using GCC, CrossWorks, and EW430. > > GCC IAR RAL > EW430 XWorks > ------ ------ ------ > Code size: 29,998 16,732 16,198 > Const size: 15,286 15,801 15,770 > ------ ------ ------ > 45,284 32,553 31,968 ...if somebody wants to add code/const sizes to this for other compilers, feel free. CODE size is size for pure code, CONST size is size for const-qualified data and strings. Read/write data are excluded from these numbers (i.e. the GCC .data and IAR/Xworks IDATA0/UDATA0 sections), but tables required for initialization of .data are included in the Const size numbers. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors
Reply by ●September 15, 20042004-09-15
That is a shockingly bad result that does not confirm with what I have observed. What version of MSP-GCC are you using? Have you compiled with the -Os flag for size, or with -O2 flag for greater optimisation? Regards Shaun -----Original Message----- From: Paul Curtis [mailto:plc@plc@...] Sent: Wednesday, September 15, 2004 11:01 AM To: msp430@msp4... Subject: RE: [msp430] Re: which C-compiler produces the smallest code size? And to say... > I compiled this for MSP430 using GCC, CrossWorks, and EW430. > > GCC IAR RAL > EW430 XWorks > ------ ------ ------ > Code size: 29,998 16,732 16,198 > Const size: 15,286 15,801 15,770 > ------ ------ ------ > 45,284 32,553 31,968 ...if somebody wants to add code/const sizes to this for other compilers, feel free. CODE size is size for pure code, CONST size is size for const-qualified data and strings. Read/write data are excluded from these numbers (i.e. the GCC .data and IAR/Xworks IDATA0/UDATA0 sections), but tables required for initialization of .data are included in the Const size numbers. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors . Yahoo! Groups Links NOTICE OF CONFIDENTIALITY The information contained in this e-mail message and in the documents attached herewith (hereinafter "the message") is intended only for the individual or the entity named above and is intended to be confidential. The reading of the message or any retention, copying, dissemination, distribution, disclosure of the existence of the message or of its contents, or any other use of the message or any part thereof, by anyone other than the intended recipient is strictly prohibited. If you received this message and you are not the intended recipient or agent responsible for the delivery of this message to the intended recipient, please refrain from reading it and notify us immediately by telephone +27 (11) 921-7900, so that we can co-ordinate with you, erasure of the message. Although this e-mail and its attachments are believed to be free of any virus or other defect, it is the responsibility of the recipient to ensure that they are virus-free, and no responsibility is accepted by this firm for any loss or damage arising from receipt or use thereof.
Reply by ●September 15, 20042004-09-15
Paul Curtis wrote: > Hi Andreas, > > >>>Actually, if you use some real benchmarks such as MiBench or the TI >>>benchmarksm GCC produces the worst code of the lot... In >> >>one case, on >> >>>an MSP430F149, it won't fit an application into flash, >> >>whereas all other >> >>>compilers do. >> >>This is contrary to my experience. Can you give numbers? > > > Ok, let's put this "GCC produces the smallest code and is a good > compiler" myth to bed, shall we? > > At http://www.rowley.co.uk/msp430/mibench.zip is the Susan benchmark > from MiBench at http://www.eecs.umich.edu/mibench/. MiBench is an image > processing benchmark and uses fixed-point math almost exclusively. > > I compiled this for MSP430 using GCC, CrossWorks, and EW430. > > GCC IAR RAL > EW430 XWorks > ------ ------ ------ > Code size: 29,998 16,732 16,198 > Const ssize: 15,286 15,801 15,770 > ------ ------ ------ > 45,284 32,553 31,968 > > The interesting thing here is CODE SIZE not CONST SIZE (which is a > fixed-size array). The code produced by CrossWorks and by IAR is half > the size of GCC. HALF THE SIZE! 30K vs 16K. ...and GCC produces small > code... Interesting. How did you get code size & const size numbers on GCC? msp430-size shows only the combined size, which is 24514 for the unlinked object (comparing library function sizes doesn't really make sense if you want to compare the code generation quality).
Reply by ●September 15, 20042004-09-15
Andreas, > > GCC IAR RAL > > EW430 XWorks > > ------ ------ ------ > > Code size: 29,998 16,732 16,198 > > Const ssize: 15,286 15,801 15,770 > > ------ ------ ------ > > 45,284 32,553 31,968 > > > > The interesting thing here is CODE SIZE not CONST SIZE (which is a > > fixed-size array). The code produced by CrossWorks and by > IAR is half > > the size of GCC. HALF THE SIZE! 30K vs 16K. ...and GCC produces > > small code... > > Interesting. How did you get code size & const size numbers on GCC? > msp430-size shows only the combined size, which is 24514 for > the unlinked object Simple, I removed all string constants from the source and removed the resized the image arrays to a single byte and recompiled. Subtract the two and you get the appropriate sizes. So, 24K for the unlinked object? Oh, and IAR and CrossWorks still beat it when compiling in all their library code *and* all the other functions requires? Gee, GCC has a long way to come, doesn't it? And IAR and RAL compile in real, working maths libraries for exp and sqrt at the same time, and still beat the stuffing out of GCC. GCC is such a soft target, really. > (comparing library function sizes doesn't > really make sense if you want to compare the code generation quality). No, you can't have this both ways. You can't say "well, GCC has unoptimized libraries, so we'll just discount those..." and say "well, code generation quality is really good!" because it's the overall package that counts. There's no getting away from the fact you *need* to use those libraries. I can compare unlinked code sizes too, but it makes no odds, GCC is not good in this crap game. It's no use comparing code generation quality of GCC over anything else because I can just subroutine all my inline sequences and produce even smaller code! You need those subroutines linked into the application, though. It's like generating a subroutine calls for x >> n where x is a long versus inlining x >> n with a loop: comparing unlinked code sizes makes *no* sense, the subroutined one will be much smaller because it just makes a call, whereas the inlined one will be much larger. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors
Reply by ●September 15, 20042004-09-15
Hi, > At http://www.rowley.co.uk/msp430/mibench.zip is the Susan benchmark > from MiBench at http://www.eecs.umich.edu/mibench/. MiBench is an image > processing benchmark and uses fixed-point math almost exclusively. > > I compiled this for MSP430 using GCC, CrossWorks, and EW430. > > GCC IAR RAL > EW430 XWorks > ------ ------ ------ > Code size: 29,998 16,732 16,198 > Const ssize: 15,286 15,801 15,770 > ------ ------ ------ > 45,284 32,553 31,968 (...) > Even considering a non-optimized floating point library, > it doesn't take up 14K of code. Can you please repeat that comparison with some code that doesn't use floats or "exotic" stuff like sqrt(), perhaps dhrystone or whatever? Regards, Patrick
Reply by ●September 15, 20042004-09-15
Shaun, > That is a shockingly bad result that does not confirm with > what I have observed. > > What version of MSP-GCC are you using? >msp430-gcc --version msp430-gcc (GCC) 3.2.3 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > Have you compiled with the -Os flag for size, or with -O2 > flag for greater optimisation? I said I used -O1. Using msp430-size to get combined const and code sizes, and with -mmcu=msp430x149 and various options I get: -O1 45,286 -Os 45,376 -O1 -Os 45,376 -O2 45,390 -O2 -Os 45,382 Thus, using -O1 and -Os together or -Os on its own is no better than -O1. So, -Os is just a no-op as far as I can see. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors
