Re: [avr-chat] Can't Install avr-gcc in FreeBSD

[David Brown]

Joerg Wunsch wrote:
> David Brown <address@hidden> wrote:
>
> > Back to gcc and other compilers - there is one area where gcc lags many
> > of 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.
>
> I have to admit I'm not very knowledgable in what linker optimizations
> can perform myself, and my C++ knowledge does not extend very far
> beyond knowing its syntax (and even then, it basically ends when it
> comes to "more recent" stuff like templates).  We're still seeking a
> volunteer for AVR-GCC/avr-libc to act as a C++ maintainer.

LTO will allow optimisations across compilation units.  Some of this 
overlaps with the sort of things --combine and -fwhole-program can do, 
but you don't have to recompile your entire program for each file that 
is changed.  This means that you can get inter-procedural optimisations 
across modules.  If a function is only ever used once, it will be 
inlined - no matter where it is defined.  If a function calls a second 
function, and that function only uses a few registers, then the caller 
can use that information to optimise register usage rather than being 
limited by the calling convention.  C++ templates should be much easier 
to work with, as most of the issues of which templates to instantiate 
will be decided by the linker.  For library projects, it will be easier 
to hide symbols that are internal to the library (greatly speeding up 
dynamic linking).  For projects on larger processors, the linker can 
re-organise code and data for better cache usage.

As for C++, I'm trying to re-learn it at the moment (after over a decade 
of using plain C).  I'm looking more at the ColdFire gcc target rather 
than avr-gcc - the AVR's lack of pointer registers is a disadvantage for 
C++.  As a language, C++ has plenty of advantages over plain C - but a 
number of disadvantages too.  Some of the syntax is truly appallingly 
ugly, which does not help.  Even more than with C, it is necessary to 
pick and choose the features you want to use when trying to write sane 
C++ code - it's easy to get lost in a maze of classes that are overly 
complex.

mvh.,

David