avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-gcc-list] Re: Code optimistaion in AVR Tiny13


From: Weddington, Eric
Subject: RE: [avr-gcc-list] Re: Code optimistaion in AVR Tiny13
Date: Tue, 17 Feb 2009 16:28:17 -0700

 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of David Brown
> Sent: Tuesday, February 17, 2009 4:11 PM
> To: address@hidden
> Subject: [avr-gcc-list] Re: Code optimistaion in AVR Tiny13
> 
> Weddington, Eric wrote:
> 
> We can always hope that the people working on gcc link time 
> optimisation 
> eventual get something working - that will make -fwhole-program and 
> -combine fairly redundant.  It seems that LTO *is* of interest to 
> companies like Google and the other "big players".

True, Google is working on LTO, but their focus is on *extremely* large 
applications and to make them smaller. So, while I like to be optimistic about 
the future of LTO, I'm reserving judgement until I see it actually working, and 
see how it works on an AVR application. But that's the other main problem: LTO 
is on a branch and is not ready for prime-time yet (but it's getting closer), 
whereas -fwhole-program exists now.

 
> Would it help if people tell Atmel that we consider avr-gcc to be a 
> selling point of the AVR's?  

I'm pretty sure that Atmel already knows that.

> I used to prefer the msp430 
> devices because 
> of their good gcc support (they are a far easier fit for gcc than the 
> AVR), but msp430-gcc has stagnated at about gcc 3.2, and avr-gcc (and 
> the library) are now far beyond the msp430 port.  This is 
> definitely one 
> of the reasons we now buy more AVR's and far fewer msp430 devices.

This is good to know! Thanks! :-)
 
> Is there much cooperation between the avr-gcc development and the 
> avr32-gcc development?

There hasn't been much in the past, but that will change significantly in the 
near future.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]