Re: [avr-libc-dev] 1.8.1?

[Georg-Johann Lay]

Erik Walthinsen schrieb:

> Honestly I've got to wonder if LLVM does this any better.  I know 
> basically nothing about it except that it's not quite up to GCC's 
> standards yet, but it might have potential and be more properly
> layered.

LLVM's structure is cleaner and the code base is younger, so there is 
less legacy code and patterns that exist for historical reasons.

In general, developers are much more comfortable with LLVM because its 
more modern structure, better documentation and modularity.

> I think extending AVR-style -mmcu into the ARM world is absolutely 
> possible, *iff* there is a shift in how devices are described as you
>  suggest.  Short of entirely new instruction sets, it should be
> possible to *trivially* define a new processor in the same style as
> avrdude does currently, and have *all* the tools reference it at
> run-time.  The only thing the toolchain should need a recompile for
> is new family opcodes, or updated optimizations.
>
> Would it be even remotely practical to do this within the existing 
> binutils/gcc/avr-libc setup?  It seems to me that if there were a way
> of removing the individual devices from the entire binutils/gcc
> codebase in favor of *nothing* but the "families" (avr5, avr6,
> atxmega5, etc.) and rewrite the -mmcu handling so it looks at a
> directory containing the relevant config, crt, linker, and even
> header files for each chip and hands them off internally (and to
> binutils) as appropriate.
>
> Basically it would be a thin *top*-level wrapper (inside gcc getopts)
>  around what Johann suggests that people do now (which I've done
> *once* in coercing gcc to compile to the attiny15), rather than
> having the -mmcu decisions made all the way down the stack.
>
> Unfortunately as I've said before, I know *very* little about the 
> structure of either binutils or gcc, having only been exposed to the 
> tiny bits that I'm messing with now.

In GCC you need one line to add a new device, namely to avr-mmcus.def in 
the avr backend ./gcc/config/avr [1].  Everything else follows from that 
 by auto-generating: t-multilib, avr-tables.opt, and even the 
documentation bit in ./gcc/doc/avr-mmcu.texi.

For binutils the one-liner is in ./config/tc-avr.c in GAS [2] without 
any auto-generated implications.

Obviously, the problem is getting one-liners into the tools.  If it's 
already too complicated to apply on-liners, I wonder how reasonable it 
is to think about implementing a framework that needs changes in the 
compiler proper (outside the AVR part)?

Johann

--


[1]
http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/

[2]
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/?cvsroot=src#dirlist