[Top][All Lists]

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

Re: [avr-libc-dev] 1.8.1?

From: Georg-Johann Lay
Subject: Re: [avr-libc-dev] 1.8.1?
Date: Sun, 02 Dec 2012 20:54:30 +0100
User-agent: Thunderbird (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 [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)?





reply via email to

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