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

[Keith Gudger]

Here are some recent numbers:

ON my application, a USB HID device implemented in the AT43USB355, in IAR
it takes 12K, in avr-gcc, it takes 16K.

The difference is that IAR has "cross-call optimization".  What this does
is look for common code snippets.  If they're longer than 2-3 words (I'm
guessing) they substitute a rcall.  It really helps in my code.  It only
seems to work inside of each source file, so your source files need to be
larger than you might think is optimum.  Part of why it works for me is
that a lot of the USB functionality is packed in just a couple of files,
giving fodder to this optimizer.

Keith

On Sat, 23 Aug 2003, Larry Barello wrote:

> 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.
> >
> 
> 
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list
> 
> 
>