Re: [avr-libc-dev] 1.8.1?

[Joerg Wunsch]

As Georg-Johann Lay wrote:

> They just add startup code, perhaps a linker script to describe
> memory on their boards and compile for their architecture.

Still, if it's not the IDE that does it on their behalf, most of those
professional ARM developers are hosed.  They solely rely on their
(often payware, like CodeSourcery) IDE to do it for them.  If the IDE
doesn't do it, they are standing in about the same rain as an AVR
developer whose device is not supported by the toolchain.

The AVR approach is somewhat more user-friendly, in that you can add
a single -mmcu option, and then compile your sources the same simple
way as you would e.g. be able to compile code for your host computer.

Technically, the way you describe would still be possible even with
today's AVR-GCC and binutils: just use the appropriate -mmcu=avrXXX
option describing the CPU core / overall architecture, use your
appropriate linker options (for SRAM start etc.) or linker script,
supply your own IO header file.  Minus a few things in avr-libc (like
power management or EEPROM support), this would work.  Right now.

Nobody does it that way.

I'd be more than happy if we could agree on the location and format of
a single external file that combines those one-liner patches you
mention, is read in by both binutils and GCC at *run-time* (so no
recompilation is needed), and would be used as a base for the
remaining decisions (possibly with a fallback to some compiled-in
device list if the file is not present).

However, that's not the way the GNU tools would currently work.  And
no, the GCC specs file wasn't really an alternative: first, it would
not work for binutils anyway.  Then, it's got an incomprehensible
syntax (even for seasoned developers), and changes were needed in many
places to add a single device.  In order to be really able to offload
new device support to the end user, it has to be a one-liner (or
perhaps, a one-record addition, like to an XML file), and it must be
possible to do this at run-time, without recompilation.

For avr-libc, this would be even harder though, as some of the device
support is really compiled in right now.  But I think if the other
tools agreed on such a central device definition file, we could start
an effort to generalize avr-libc as well (perhaps accompanied by a
script that recreates some of the device-dependant header files from a
template file, based on those device definitions).
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)