[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] 1.8.1?
Re: [avr-libc-dev] 1.8.1?
Sun, 02 Dec 2012 20:54:30 +0100
Thunderbird 184.108.40.206 (Windows/20100228)
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
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 . 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  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)?