[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/
Re: [avr-gcc-list] ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/ATMega2561
Mon, 12 Sep 2005 22:23:44 -0500
Mozilla Thunderbird 1.0.6 (Windows/20050716)
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
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.
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
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
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
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
+ (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?