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 <eric.wedding...@atmel.com> wrote: > > >> -----Original Message----- >> From: Andy H [mailto:hutchinsona...@aim.com] >> Sent: Thursday, December 17, 2009 6:46 PM >> To: Dusan Ferbas >> Cc: Andrew Hutchinson; avr-gcc-list@nongnu.org; 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 > AVR-GCC-list@nongnu.org > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list > _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list