Re: [avr-libc-dev] Change EEPROM SFR definition.

[Marek Michalkiewicz]

On Thu, Jun 30, 2005 at 10:31:59PM +0200, Joerg Wunsch wrote:

> Btw., I'd really like to see the EEPROM issue fixed for the next
> release of avr-libc, one way or the other.  I'm a bit reluctant to
> move the entire EEPROM handling into inline functions (for possible
> code bloat reasons) but unless we can come up with a per-device
> library solution quickly, I think the inline/macro approach would at
> least be fine as a workaround that can even be applied inside the 1.2
> version line.

I have a suggestion for a per-device library solution, but (as usual)
the transition needs some attention to backwards compatibility issues...

1. avr-libc installs (initially empty) libavr-$device.a libraries
(where $device is device name as in -mmcu=... for all known devices).
While you are at it, install copies of crt*.o as crt1-$device.o too.

2. add "%{mmcu=*:-lavr-%*}" to LIB_SPEC in avr-gcc mainline:
now -mmcu=atmega128 will search for -lavr-atmega128 before -lc
(so the device-specific library can override parts of libc.a).

3. avr-libc adds per-device stuff to libavr-*.a (only avr-gcc mainline
with the above changes will find it).

4. after the next stable GCC release, backwards compatibility stuff
in avr-libc can be safely removed (device-specific code _only_ in
libavr-*.a, only portable C code in libc.a).

The idea is to have both generic libc.a (per-architecture multilibs -
anything not using I/O registers, only different instruction sets) and
libavr-$device.a for truly device-specific code (like EEPROM).
The (many) device-specific libraries would be very small, so build
times or disk space should not be an issue.

Marek