[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: Tue, 04 Dec 2012 08:56:02 +0100
User-agent: Thunderbird (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 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:
- 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
- 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.



reply via email to

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