Re: [avr-gcc-list] ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/ATMega2561

[Chip Webb]

> > Is anyone working on a port for ATMega64x, ATMega128x and ATMega256x
> > devices?
> >    
> Yes and no.
>
> Patches for the 640/1280/1281 are reasonably complete, support to
> avr-libc has been added by Anatoly Sokolov recently.
>  
OK, thanks. The 640/1280/1281 patches are a help.  I was working on my 
own versions in spare time
and will try to sync up with Anatoly's. Have  binutils and gcc have also 
been updated as part of
the patches? If so is it in CVS? (I hope that's not a dumb question).

> Regarding the mega256x support, the issue has been discussed here a
> number of times.  Not much progress on this so far.
>  

The hard part, as I recall from earlier discussions, is the 2560/2561. 
It seems to me that the
hard part boils down to handling the conversion of ICALL/IJMP to 
EICALL/EIJMP
to support the larger program memory space of the 256x devices.

It seemed as though there were two proposed methods to handle this:

1) Align functions (and labels?) to 4-byte boundaries so that  gcc can 
continue to use 16-bit
  values to represent function pointers.  This isn't so different from 
the method that is
  already used for the Mega128.

2) Modify GCC to support longer pointers (PSImode?)

I understand method (1) better than I understand method (2).

    + (1) seems relatively easy to implement (emit .align 2 at the 
right places
         and add code to do the shifts and loading of EIND:Z before
         calling EIJMP/EICALL. Also add three more "pm" style relocation
         types to bfd and gas.

    - (1) using ".align 2" is a minor waste of program memory but we're 
talking
           about doing this only on devices with 256k flash so the 
impact is probably
           insignificant as long as the number of functions (and 
labels?) is not
           unusually high.

    +  (1) Pointers stay 16-bits so that storing them requires the same
         amount of SRAM.

    - (1) I've not thought much about but program memory strings
           but since WinAVR arranges for them to be in low memory
           addresses (above the interrupt table), I'd have to have a lot
           of program space strings to require longer pointers.

    = In both (1) and (2), the libgcc and avr-libc routines that use
           IJMP (like __prologue_saves__) the assembly code would
          have to be modified and I don't think it matters whether (1) or
          (2) is used.


Does that pretty much sum it up? Am I missing anything?

Thanks!

Chip Webb