|
From: | David Brown |
Subject: | Re: [avr-chat] Can't Install avr-gcc in FreeBSD |
Date: | Wed, 22 Aug 2007 23:56:18 +0200 |
User-agent: | Thunderbird 2.0.0.6 (Windows/20070728) |
Eric Weddington wrote:
-----Original Message----- From: address@hidden [mailto:address@hidden On Behalf Of Joerg Wunsch Sent: Wednesday, August 22, 2007 1:28 PM To: address@hidden Subject: Re: [avr-chat] Can't Install avr-gcc in FreeBSD David Brown <address@hidden> wrote:Back to gcc and other compilers - there is one area wheregcc lags manyof the big names in commercial compilation. ... ..., but what is lacking is proper link time optimisation.My guess is this is mainly lack of experience with those features by the GCC developers, rather than lack of the tools. For example, Björn Haase recently implemented linker relaxations for the AVR, which is something I've already noticed (supposedly, in IAR generated code) when disassembling the first JTAG ICE firmware years ago. Still, until very recently, there wasn't even the respective -mrelax option available for AVR-GCC, you had to make your way through -Wl,-relax in order to use it. Anatoly recently changed that, as I understand.FYI, GCC does have an "LTO" project (Link Time Optimizations) that I guess several people are working on. It has it's own branch in the GCC repository. There was a talk about some of the LTO stuff at the most recent GCC Summit. There are some pages on it in the GCC wiki. Start here: <http://gcc.gnu.org/wiki/LinkTimeOptimization> So the GCC folks *are* working on it. Stuff like this takes time as, by nature, these folks are very conservative when making changes. They don't want to break things in the middle when they're adding things. Offhand, I don't know the schedule for inclusion of this. I tend to doubt that it will get included in 4.3. My gut feel is it might be in 4.4. But I could be horribly wrong. Eric
I read about the LTO project a few days ago (which is what made me think of it). It seems people started looking at LTO for gcc about five years ago, yet it is still very much a work in progress - gcc 4.4 would be an optimistic (though not unrealistic) guess. I understand that this is fairly hard stuff for gcc - it breaks the traditional sequence of phases of C compilation, and the gcc developers do not introduce such large changes without being very sure that it will work. gcc's strengths in its portability and wide-spread use are also its weakness for this sort of thing - the changes have to work for half a dozen languages, several dozen targets, and vast ranges of projects from small embedded systems to huge desktop application projects.
mvh., David
[Prev in Thread] | Current Thread | [Next in Thread] |