[avr-gcc-list] IAR vs GCC (Larry Barello)

[TODD BATZLER]

My company is currently using the IAR Embedded WorkBench as the "official" 
compiler for product development. I've been using GCC for everything of a 
personal nature.  I've been struggling with GCC over a feature that IAR makes 
very pain free, which is placing a string of bytes at an absolute location in 
the code segment, then having the linker to be smart enough to "wrap" the other 
code segments around this absolute segment so as to not waste large chunks of 
the CODE section.  I've managed to dig up enough information on linker scripts 
to modify one to create the required absolute field in the rom image and place 
my required data there.  However, if my relocatable code gets larger than my 
absolute address minus the start of the .text section, I get a warning that the 
linker location counter can not be "backed up".  Which makes sense.  Any ideas 
on how to instruct the linker to check the available space between defined 
section starts and any absolute sections and then have it figure out when it 
can place code in that section (if it will fit) or place it after the absolute 
section (if it will not)?

Also, do you know how to find out what was specifically done to the "avr-" 
variants of the GCC binaries to make them different from the "standard" GCC 
release files.  I'm assuming that support for some of the architectures was 
removed, plus a bunch of other things.  There's no specific documentation for 
the avr-ld, avr-objcopy, etc files.

Thanks for the attention.

Todd Batzler
address@hidden 

>>> address@hidden 06/12/01 07:01PM >>>
Send avr-gcc-list mailing list submissions to
        address@hidden 

To subscribe or unsubscribe via the World Wide Web, visit
        http://avr.jpk.co.nz/mailman/listinfo/avr-gcc-list 
or, via email, send a message with subject or body 'help' to
        address@hidden 

You can reach the person managing the list at
        address@hidden 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of avr-gcc-list digest..."


Today's Topics:

   1. IAR vs GCC (Larry Barello)

--__--__--

Message: 1
From: "Larry Barello" <address@hidden>
To: "avrx" <address@hidden>,
        "AVR GCC List" <address@hidden>,
        "avrchat" <address@hidden>,
        <address@hidden>
Date: Tue, 12 Jun 2001 11:05:29 -0700
Subject: [avr-gcc-list] IAR vs GCC

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 







--__--__--

_______________________________________________
avr-gcc-list mailing list
address@hidden 
http://avr.jpk.co.nz/mailman/listinfo/avr-gcc-list 


End of avr-gcc-list Digest