Re: Re[2]: [avr-gcc-list] Re: GCC-AVR Update (20082003)

[Larry Barello]

The last time I compared IAR & GCC was about 2 years ago and IAR had marginally 
smaller
code size, but much fatter and slower libraries (for my projects).  The end 
result was a
slight edge to GCC.  This is only for small model code, which is all that GCC 
supports.

>From what I heard, IAR now implements some sort of "code compressor" where 
>they look for
strings of op-codes and replace with function calls, globally.  This can really 
crunch
the code size, if you like that sort of thing.

Anyway, at the time I did my comparison (GCC, IAR, ICC and CV) the note I wrote
apparently found its way into an Atmel AVR seminar where the local FAE were 
using it to
show low cost quality tools were available.

Perhaps and updated comparison with an objective analysis of the pro/con would 
go a long
way towards either focusing the GCC efforts, or convincing Atmel to give us 
better
support.

Cheers!

----- Original Message ----- 
From: "James Dabbs" <address@hidden>


> > An  Atmel  engineer  here in Germany I spoke to on the phone yesterday
> confirmed  that  gcc  indeed
> > is "a really nice compiler" for AVR. But frankly  I  think  it  would take
> one order of magnitude less
> > bugs and maybe  a 1/3 or 1/2 cut in code size on gcc's part (impossible I
> know) to  really start sucking
> > away customers from IAR and stir things up at Atmel.  With  regard  to
> bugs I'm not so sure, but with
> > code size I'd have to quote grand ma: "Not gonna happen". ;)
>
> This was not my experience.  I evaluated IAR (for a project that now seems
> to be defunct) and it was a really nice environment and it had a good
> debugger.  But the compiler output in my case from IAR was *bigger* than
> GCC, and in fact wouldn't fit into the part.  This was with the IAR
> optimizer on full blast, favoring small code, compiling C++ source.  Also a
> section of code (the XTEA encryption algorithm) caused IAR to emit bad code
> at maximum optimization, while GCC dealt with it.
>
> I also think that GCC's inline assembler, in extended mode, can't be beat.
> Especially with a little part like the AVR and an understanding of the ABI,
> you can really pick out and optimize problem spots.
>