RE: [avr-gcc-list] Support for ATMega256 and ATMega2560

[Geir Tore Olsen]

Hmm, quite a bit of work in other words.

I do have a preliminary datasheet for the devices. I can e-mail it off-list
if you guys are interested. I'd be willing writing up those headerfiles if
not allready done. The compiler stuff is a bit out of my league tho.....

Best Regards
Geir Tore Olsen

> > Simply adding headers to avr-libc is not sufficient. Also, there's a
> > few places in avr-libc that use RAMPZ under the assumption that it
> > is either 0 or 1 which will have to be changed.

Where exactly?  Startup code uses ELPM with RAMPZ:Z post-increment
so this should be no problem.

> Wouldn't bumping the memory size above 128 KB (= 64 KWords) even affect
> the way `long' jumps/calls have to be handled?

Without the datasheet (not available yet) - looking only at the
instruction set manual - I can see that JMP and CALL opcodes are
actually the same (they already have room for 22 bits of program
memory address = max 4M words).  But, there are other problems:

 - return address uses 3 (not 2) bytes on the stack (GCC needs to
   know this to use correct offsets for function args on the stack)

 - 2 bytes are not enough for function pointers, possible solutions:
    - require that if you take the address of a function, that function
      must be placed in the low 64K words (special section? - I don't
      know if the linker can do that automagically)
    - align functions so that a few low bits of the pointer are always
      zero, and store pointers shifted right; at runtime, shift the
      pointer left and load the high bits into EIND, then use EICALL;
      EIND must be saved/restored if used in interrupt handlers
    - add support for 3-byte (PSImode) pointers to GCC - this may be
      quite a lot of work, and all pointers will have this size
      (not just program memory pointers, because GCC core doesn't
      support pointers of different sizes as far as I know)

 - new linker script is needed, allowing larger program memory size

 - all the usual issues with multilibs, as with any new device

This list may be incomplete - it's just a start...

Marek