AVR-Chat

The last time I directly compared avr-gcc, IAR, ICC and CV was over three
years ago (maybe four).  IAR was the best in terms of local code density.
GCC was close behind.  ICC and CV were distant third place.  And I mean
DISTANT.

What kept me with GCC was a) free vs $1500 and b) for my overall project GCC
produced a smaller load image and c) the IAR compiler achieved the compact
code in two ways: It called lots of prolog and return routines and it used
two stacks (call return & parameter).  This is great for single threaded
code, but at the time I was writing multi-tasking kernels and supporting two
stacks/task was very inefficient. In short, the libraries that came with GCC
(Floating point, stdio, etc) were very, very tight (hand tuned assembly).
GCC was also faster in that all prolog/returns were in-line (you can specify
called if you want). 

GCC is absolutely dynamite when using pointers and dereferencing data
structures.  My test, at the time, was PID & Navigation routines that were
based upon structures so I had left/right/etc and used the same code for
each (passing in a pointer for the one in question).  GCC produced
astonishingly good code: GCC can "remember" where things are and avoid
re-loading or re-calculating data.

Still it can be pretty stupid about other things, and, over the last couple
years has actually gotten worse with code density.  The very thing that
makes it great also hinders it: It works across zillions of different CPU
targets and hosts.  It takes serious developers to tune the AVR specific
code for good results.  The register save/restore for interrupt handlers is
one area that could use work.  That must be why I, over time, re-wrote my
common handler in assembly (USART, quadrature encoders, anything that is
really high speed).

Since I last compared compilers ICC has come out with procedural abstraction
(look for common snippets of code and turn them into subroutines).  This can
compress code down very tightly, but, of course, it becomes completely
un-debuggable and much slower.  

So, if you have $1500 to burn and want the best: IAR.  If you want second
best and are willing to bleed a bit in the ears and nose but otherwise not
pay any money, GCC.  If you want pretty interfaces and IDE's and easy
out-of-the-box getting started: CV or ICC (Code Vision/ImageCraft).  If you
are willing to look at the generated code periodically and adjust your
programming style (i.e. abstract code and pass pointers around) you can get
very tight code with GCC.

IMHO the floating point support of GCC alone is worth the hassle: It is
about 1kw of code and takes ~500 cycles per floating point operation (about
1.6kfp/mhz clock for a couple multiplies, sin() and cos() operations).
Absolutely dynamite that none of the other compilers can begin to touch.  It
is practically a religious experience reading through the code.


Cheers!

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Don Ingram
Sent: Wednesday, August 17, 2005 3:33 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Differences between C compilers

  Also, code efficiency and optimization
> differ between compilers.  An Atmel FAE told me that most folks say that 
> GCC-AVR is almost as good as IAR (who is the best currently).

This was what I was lead to believe too, but an example shown here a few
weeks 
ago dispelled that myth. If I recall correctly ( & I may not ;-)  the
particular 
example was the overhead in entering / exiting an interrupt ( fading
memory... 
). The particular example compared the overhead between GCC & CVAVR, the 
difference was substantial. Someone more knowledgeable may wish to clarify
this.

Cheers

Don