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

[Sean D'Epagnier]

I am not sure that everyone wants avr to have multiple address spaces
handled by the compiler.  The reason, is that now pointers are 3 or 4
bytes not 2 which makes for larger code size and slower execution.
The current way forces code to look ugly, but gives the programmer
more control  and more speed.  I like to write programs which generate
the c code gcc compiles (this is another way to get around the problem
and does not sacrifice execution speed or size)

I might take a looks at how the multiple address spaces is
implemented.  My guess is that simple operations that used to read a
byte from say ram, now they will  require a function call which
branches based on certain bits in the pointer for flash, eeprom, ram
etc..  Of course optimizations for memcpy or string functions could be
optimized to only need 1 branch, not for every byte.

Also, all of the library functions for program memory (_P) functions
would go away, and support for %S could be deleted.

Sean


On 12/17/09, Weddington, Eric <address@hidden> wrote:
>
>
>> -----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
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>