[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?
Tue, 04 Dec 2012 08:56:02 +0100
Thunderbird 22.214.171.124 (Windows/20100228)
Joerg Wunsch schrieb:
The problem with supporting new devices is, without a corresponding
addition to binutils and GCC, it could not even be compile-tested in
If it's really the case that avr-libc waits for avr-gcc -mmmcu=device
and the compiler waits until avr-libc supports Device, it's a good idea
to disentangle that chicken-egg.
I still think that users who really need device support -- at least some
of them -- are brave enough to use the -mcpu=core approch /provided/ it
is comprehensible and that support reasonably complete (which is not the
case at the moment because (1), (2), (7) and maybe (8) from below are
1) When building avr-libc, probe -mmcu=device and in the case there is
no support, probe -mmcu=core. If support is there, install crt.o no
matter whether compiler or binutils support -mmcu=device. Always
install available io.h.
2) Add gcrt1.S source to the install so it can be picked up be users.
Rewrite gcrt1.S so that the only thing it needs is io.h. In particular,
remove the dependency from macros.inc and sectionname.h which is easy.
3) Using -mmcu=core will work with gas if the core ships all information
about the ISA. Currently, this is not the case for:
- Load-modify-store: XCH, LAS, LAC, LAT
4) It's a good idea to resolve the GCC / Binutils dependency, i.e. add
supplement options like -mdes and -mldmst that tell binutils about the ISA.
5) If that support is mature and thus the compiler may assume that
binutils comes with these options, there is no more need to add
-mmcu=device to binutils. Better have only 2 places to change than 3.
6) The compiler needs new rows in avr-mcus.def that tell
- the core to provide to gas
- the ISA flavors like have / don't have DES
This will work like -msp8 at the moment: If the compiler is called with
a device, it ignores -msp8 because it knows better. If the compiler is
called with a core, it uses -msp8 as supplement to avr2 and avr25. All
that's needed is a new specs function in ASM_SPEC / driver-avr.c.
7) There should be a central "registry" that tells about device
capabilities and properties like:
- What core is it? avr4, avrxmega4, ...
- What ISA is it? DES, XCH, SP size, core bugs to work around, ...
- More hardware information needed by the tools: RAM start, ...
- Conventions about representation by the tools: -D<??>, crt<??>.o, ...
A major problem at the moment it that nobody knows this, cf.  for
example. If not even that information is available, anything else is
pointless. If it's unknown what device has what ISA, there won't be
patches that add respective support of course.
8) If there are device headers available for Atmel, but users must not
use them in their applications for licensing issues, Atmel should think
again. I don't think it makes any sense for volunteers to proceed if
that's actually the scenario...
9) It's no good idea to implement a registry that has to be read at run
- It's hard to implement and needs changes outside the avr backend
- Same even for a specs approach that includes a specs snippet
- The help screen would not display supported devices
- MULTILIB_MATCHES must be there at build time.
- Nobody will go through the trouble to implement a GCC plugin
that implement this! Notice that only a GPL plugin makes sense.
Otherwise, the compilation process is no more eligible.
However, main objection is that the current blocker is missing
information about device properties. Implementing whatever framework
will not close that information gap (7) and thus is pointless without