Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>

[Marek Michalkiewicz]

On Mon, Dec 20, 2004 at 10:41:21AM -0700, E. Weddington wrote:

> As a side OT note: This is another desired feature, to go to per-device 
> multi-libs. And perhaps this can be done in conjunction with a possible 
> move to newlib.

With the large size of newlib compared to avr-libc, and Atmel making
lots of new devices easily (where often a few variants differ only in
memory sizes), I'm a bit worried about the total size and build time...

Almost all of newlib is not hardware-specific, so multilibs would
really only be needed for different instruction set variants.  There
aren't as many of these as the devices themselves.  As I proposed
some time ago - instead of a flat list, multilibs should ideally be
based on a few independent properties of a device:

 - MOVW supported: yes/no
 - MUL (etc.) supported: yes/no
 - stack pointer: 16-bit/8-bit  (possibly make all pointers 8-bit
   on such small devices - but, this might break some code which
   assumes that pointers are the same size as "int"...)
 - max program memory size: 8M/128K/8K

This results in 2*2*2*3 = 24 combinations of options, but many of
them can be excluded with MULTILIB_EXCEPTIONS, so about 10 remain.

The "really per-device" stuff (interrupt vectors, EEPROM access,
timers, etc.) could go into separate, small per-device libraries.
This would be instead of the current crt*.o files (just more
flexible - libraries instead of single object files), and since
this is mainly assembler code, it is small and fast to build.
This could be made a separate package (not part of newlib), along
with the AVR-specific header files.  Only that package (and not
newlib itself) needs to be modified to add support for new chips.

The main problem with all this is backwards compatibility.  It may
be easier to start from the beginning (much like we did a few years
ago, during the AVA->binutils transition), with a completely new
GCC target configuration, say "--target=avr-newlib" (keeping the
old "--target=avr" one, until the new one is stable).  This time,
I'd suggest only _one_ ld emulation (with the maximum possible
memory sizes in the linker script).  Doing it per-device (as was
the case in the past) has already turned out to not scale well.

And, another problem: you asked for my opinion, and here it is.
But, I'm not the one to do all the work :) - unfortunately,
I don't have as much time as I had a few years ago...  So, my
opinion is really only a suggestion - not a strong opinion, even
if it sometimes sounds so...  You are doing most of the work, so
you know how to do it best.

Regards,
Marek