RE: [avr-gcc-list] Why are we using EICALL and EIJMP for AVR256?

[Weddington, Eric]

> -----Original Message-----
> From: Andy H [mailto:address@hidden 
> Sent: Thursday, December 17, 2009 6:46 PM
> To: Dusan Ferbas
> Cc: Andrew Hutchinson; address@hidden; Weddington, Eric
> Subject: Re: [avr-gcc-list] Why are we using EICALL and EIJMP 
> for AVR256?
> 
> 
> It is not possible to handle EIND inside gcc (before gas and linker). 
> Pointer are only 16 bits

In GCC HEAD, which is future 4.5, there is a new "multiple address space 
feature" that was recently added and is being used in the spu port, and 
recently one other port. Ideally we need to:
- Have the avr port use the multiple address space feature. This will also let 
us have the ability to have pointers to flash, pointers to ram, pointers to 
eeprom, and read data out of flash into ram and have gcc generate the lpm 
instructions for this.
- With multiple address spaces, we can have multiple pointer sizes. We need to 
set the pointer size according to the memory size so that the atmega256x 
devices will have (nominally) 24-bit pointers, but smaller flash sizes (such as 
atmega128) have a 16-bit pointer. With 24-bit pointer sizes, we can get rid of 
the 'trampolines' that cause so many problems and confusion. The trampoline 
idea, when it was implemented, was a compromise anyway and it was known that it 
was a bit of a kludge.

Granted this may be a lot of work, but this is the direction that the avr port 
must go in.

Eric