[avr-gcc-list] RFC: new AVR devices in binutils

[Marek Michalkiewicz]

Hi,

looking more at adding complete support for all these new devices (not 
only ATmega128), I'm not really sure what to do, as there are a few
problems...  Basically, Atmel made too many different chips and didn't
tell us (without all this super top secret NDA crap) early enough.

Looking at publicly available datasheets (some of which may describe 
non-existent devices... but most of them are real), there are about
20 different combinations of Flash size, SRAM size, EEPROM size, and 
start of data memory (0x100 on ATmega64/128, 0x60 otherwise).  I don't
think it's a good idea to add so many ld emulations, and add more when 
Atmel comes up with even more different chips...  So here is the plan,
please tell me if it makes sense :)

 - add 5 new emulations, one for each "architecture" avr1 ... avr5
   with default linker scripts defining maximum possible memory sizes:

        arch    flash   SRAM    EEPROM
        avr1    8K*     0       64K
        avr2    8K      64K     64K
        avr3    128K    64K     64K
        avr4    8K      64K     64K
        avr5    128K    64K     64K

   (* Yes, I know the largest avr1 now has only 2K - ATtiny28 - but who
   knows if/when Atmel makes some ATtiny89 or something like that...
   the idea is that it is possible to address max 8K of program memory
   using the avr1 instruction set.)   In linker scripts for these new
   emulations, define start of internal SRAM as 0x60, and don't define
   __stack at end of SRAM (as we don't know the real size).

 - keep the existing avr85xx etc. emulations for now (may be removed
   later, when no longer used for a few years...).

 - change LINK_SPEC in gcc/config/avr/avr.h to specify -Tdata 0x800100
   for ATmega64/128 so variables start above I/O registers.  The default
   (0x800060) is good for all other devices so there is no problem.

 - change avr-libc to define __stack as a weak symbol in gcrt1.S (as
   avr-libc has one crt*.o file for each device type anyway).  It is
   weak so can be redefined - old linker scripts that do will not fail.

 - after the next stable release of binutils, change GCC to use the
   new avr[1-5] emulations for all devices, not just the new ones.

 - then, after the next stable release of GCC, the old avr85xx etc.
   emulations may be removed from binutils.

The good thing is that after all this, new devices should not need
big changes in binutils to be well supported.  Especially adding
emulations is a pain - I don't have the right combination of
autoconf/automake versions to regenerate all these files correctly.
Makefile.in and configure end up being different in a few other places
where I didn't change anything, and (tested on CVS binutils today)
automake in "gas" subdirectory fails :(

So I guess I'll have to politely ask binutils maintainers to regenerate 
these files for me (as they know some magic that I don't know...),
hoping I won't have to do that again too often...

The disadvantage is that we lose size checking (the linker won't detect 
that the program is too big for the device).  You have to write your
own linker script with correct memory sizes, or look at avr-size output.
But that size checking was not reliable anyway: no error if text < 8K
but text+data > 8K, so looking at avr-size output (or map file) is
necessary anyway...

Basically I try to preserve backwards compatibility between current
stable releases of GCC and binutils.  That's why I'd like to add new
emulations soon, but remove the old ones after no one uses them.

Also, there is no need to edit linker scripts for external SRAM support
(how to do this is a Frequently Asked Question).  Only set up MCUCR
correctly (avr-gcc -Wl,--defsym,__init_mcucr__=0xC0) and that's all.
(This could probably be done by inserting some "asm" in C source,
which could define that value using symbolic names from <io*.h>.)

It was partially my fault that I didn't expect so many new chips when
making changes to support atmega163 etc.  Hopefully I won't make so many 
mistakes this time...  I'm very busy, but I want to do this so people
stop sending me so much mail about ATmega128 support :)

Comments and suggestions welcome.  Could this plan be improved?

Thanks,
Marek
avr-gcc-list at http://avr1.org