compiler differences, tuning, linkin together

rainer32 wrote on Friday, April 28, 2006:

hi all,

Richard pointed out that plain arm-elf-gcc uses more stack than rowley, which in turn uses more than iar. so i’m looking at ways to reduce the stack size used with gcc and optimize it as far as possible.
- do you have any suggestion about what configuration parameters or other ways might tuning arm-elf-gcc? (and how does rowley do it, if it’s based on gcc?)
- do i understand it right that the amount of stack size eaten up (i’m not talking about the amount allocated) depends on the compiled code in a way that the optimization is to be searched for in the compiling stage, not at the linking stage?
- last time i used iar was a while ago with msp430 , and it seemed to be 100% gui-bound. is there also a command-line compiler included?
- is it practically feasible to link together stuff compiled separately with iar and gcc?
- as it’s openly available for a multitude of host OSes (including linux) and target architectures and since i feel at home with gcc, make etc (and like the way it’s all open), i have pretty much standardized all i could on gcc and feel reluctant about changing to a proprietary compiler suite. right now, apart from the bigger stack size (which isn’t so problematic), i’m quite happy with gcc. I 'm still a little fresh with arm and FreeRTOS though, so is there any other problem about arm-elf-gcc that i should know about?
- any other ideas or comments related to optimizations of gcc or how to get them to work together?


rtel wrote on Saturday, April 29, 2006:

GCC is a generic compiler targeted at a whole multitude of processors and systems.  The compiler itself is very good at optimising (IMHO) and therefore good for microcontroller use, but the libraries that come with it were no written with small microcontrollers in mind.

From what I have read regarding (non bias) comparisons between ARM compilers the libraries that come with GCC are its major downfall due to the stack they consume.  In most embedded applications this is not really an issue, but when you start doing lots of string manipulation for serving html then you are going to start using strcat, strlen, strcpy, etc, etc.

If you can, isolate all the code that uses these libraries into one or two tasks, then just allocate more stack to these tasks.

There may be other libraries around you can use targeted specifically at smaller devices.

In the past, if I have just required a few library functions, I have written them myself rather than include the versions that come with the compiler.  For example, I did this in the WIZnet WEB server demo.

As far as IAR goes, you can call the compiler from the command line just like GCC, but I would not attempt to link IAR and GCC code together.


rainer32 wrote on Saturday, April 29, 2006:

thanks for the information.

there’s just one thing i’m not sure about concerning the libraries: most every arm-elf-gcc toolchain out there doesn’t use the gnu libc (glibc) as the standard c library, but newlib (which pretends to be programmed specifically for embedded stuff and smaller resources). i thought the c string functions and others of the kind were in there. obviously, newlib (as a general, platform-independent libc) is still not at the highest level of optimization.

for atmel’s smaller avr family, there’s a specially optimized open source libc (avrlibc). i guess that’s missing for the arm family.

thanks for the info