[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chip Webb
Subject: Re: [avr-gcc-list] ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/ATMega2561
Date: Mon, 12 Sep 2005 22:23:44 -0500
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Is anyone working on a port for ATMega64x, ATMega128x and ATMega256x
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?


Chip Webb

reply via email to

[Prev in Thread] Current Thread [Next in Thread]