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

[andrewhutchinson]

If it were implemented, it just gives different pointers for different spaces. 
Thus RAM would still be 16bits.
The different pointer types would then allow the correct move instructions to 
be used.
Though this is not a done deal - since the allowable addressing modes and 
associated registers are highly restricted for flash access.

It does not provide universal pointer like you describe. Though this is 
possible, it would create much larger code for the reasons you list.
I think IAR can optionally do this for MSP430



---- Sean D'Epagnier <address@hidden> wrote: 
> 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
> >