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

[Theodore A. Roth]

On Thu, 13 May 2004, Marek Michalkiewicz wrote:

> On Thu, May 13, 2004 at 09:44:40AM +0200, Joerg Wunsch wrote:
> > "Theodore A. Roth" <address@hidden> wrote:
> >
> > > 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.

I just grep'ed for RAMPZ in the include/avr/ (head only). The boot.h
and the pgmspace.h files look clean and ready for >128K. I think I just
got confused with my mega128 bootloader I wrote for work which I had to
manually handle the RAMPZ register to save the space of the 32 bit
address access.

Sorry for the confussion.

>
> > 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)

I think gdb would need changes to handle this too.

>
>  - 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)

This sounds like the easiest option to implement. Although, we already
kind of force PROGMEM into the lowest 64K too. I wonder how long before
that space starts getting cramped? Probably not an issue though.

If it possible for gcc to detect that a function is being referenced by
pointer (e.g. this is really just looking for the function in the RHS of
an assignment) and then pasting on some attribute for the linker to use
to place it in the lower 64K? That may not be feasible, but if it is,
then it remains transparent for the end user.

>     - 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

This has been done in gdb for other targets but I think those targets
may have done this in hardware though. I don't think this scales well to
handle the whole 22-bit address space.

>     - 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)

I don't have any experience with this.

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

Shouldn't be too hard.

>
>  - all the usual issues with multilibs, as with any new device
>
> This list may be incomplete - it's just a start...

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden