Re: [avr-libc-dev] 1.8.1?

[Georg-Johann Lay]

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
> avr-libc.

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 
missing).

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:
- DES
- 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. [1] 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
   time:
- 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 
that information.

Johann


[1]
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=963295#963295