[avr-gcc-list] IAR vs GCC

[Larry Barello]

I have ported my rtos (AvrX) from GCC to IAR (ICCAVR).  Well,  I ported it
such that it can be built for either.  Anyway, I thought I would share my
results with code size and my experiences with the porting process.

IAR has some heavy duty code crunching optimizations that look for common
groups of code and sets up lots of little subroutines.  The mileage varies.
For a bunch of, admittedly, trivial applications I got the following:

<view with fixed pitch font like Courier>
File                    GCC -Os    IAR -z4    IAR -z9
-----------------        -----      -----      -----
TestCases/BasicTest1      158        185        161
TestCases/BasicTest2      492        631        421
TestCases/BasicTest3      766        779        533
TestCases/BasicTest4      322        379        321
Examples/Timers           164        163        157
Examples/Messages         182        209        195
Examples/MessagesAndData  178        171        167
Examples/MessageTimers    244        261        233
Examples/MessageTimersAlt 248        273        257

I have ported my application code for my robot Dilbert II, about 1/4 is
assembly code (8535):

Dilbert II (no float)     7414        ----      7325

Floating point support: My robot uses Michael Stumpf's floating point
library (gcc -lm), when I enable the floating point support in Dilbert II
here are the resulting sizes (mega163)

Dilbert II (with float)   9582        ----     10385

Interestingly enough, the overhead is totally from the library, the IAR
code for the module that uses float is smaller than the GCC (991 vs 1204
bytes)  I don't know how good Michael's library is, but in terms of size
and
speed it is very good.

It appears that IAR has some fixed overhead and that the code savings grows
with size.  The -z9 does a good job of finding common blocks, but sometimes
the resulting code has lots and lots of rcall/ret to small three and four
line common blocks.  That could really slow down an application and/or blow
out the stack.  I think a good C programmer might naturally pull out common
segments into subroutines and the savings won't be as dramatic.  Overall,
however, it appears that GCC does an equivalent job as IAR for a completed
application.

IAR has very lame in-line assembly vs. GCC.  That is a two edge sword!  It
is easy to get in trouble with GCC and never figure it out.  On the other
hand you can do much more powerful and slick tricks with GCC if you know
how.  Many AVR specific features of GCC are nothing more than clever macros
with smart inline assembly fragments.  To be fair, most things I have done
with in-line assembly could also be done as callable asm routines with
little additional overhead.  It is harder to get into trouble that way.

GCC has a nice way of managing the chip variants.  For the most part one
just specifies the chip and away you go.  With IAR, currently (they are
moving to a GCC style of header files), you have to specify different
headers and linker files to build for a different target.  I don't know
Embedded workbench, maybe they have this solved, but it is a pain with
makefiles. For both compilers one gets into magic very quickly when
enabling external RAM.

IAR uses a separate data stack for passing parameters, saving registers,
etc.  This means that for each C task one needs to specify TWO stacks.  The
resulting fragmentation of SRAM is less efficient than GCC.  I suppose the
IAR way conserves a few cycles.  I prefer the GCC technique because it is
simple and I only have to look at one stack to see if I need more room or
not.  With IAR one needs to fiddle with the linker files to set the stack
space.  With GCC one needs to pass symbols to the linker.  Both techniques
are reasonable, just different.  Since GCC defaults the stack to the end of
SRAM typically nothing needs to be done.  The only time it gets sticky with
GCC is if you have external SRAM and want your stack in on-chip ram (faster
access).

GCC compilations seems much faster, although, realistically, 9 seconds for
IAR vs. 7 for GCC to compile a complete application for an 8535 on a
relatively old PC doesn't amount to much.  Unless one was filling a mega103
one just can't have enough code to make a big difference!

I have not played with C++ at all so I cannot comment on that part of GCC
vs. IAR.  IAR has a subset of c++ tuned for the AVR processor, I guess.

Of course, debugging with IAR and astudio (atmels simulator/debugger) is
much, much better than GCC.  I have never used GDB, but I assume it has
similar data representation abilities.  With IAR it is so nice to be able
to follow a pointer to a structure with pointers to more structures (e.g.
linked list) and see the data change between breakpoints.  I hear that
astudio 4.x will include .elf support and so viewing GCC C data structures
should be fully supported at that time.

Larry Barello
http://www.barello.net
http://www.barello.net/avrx
http://www.groups.yahoo.com/group/avrx