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

[David Brown]

Weddington, Eric 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

Multiple memory spaces are definitely a nice idea, and will (hopefully) 
help make source code neater.  But there are a few things to be wary of, 
I think.

It may be nice and elegant in the source code to have a pointer to 
eeprom that can be used much like a pointer to ram - but that will mean 
that innocent-looking C code can actually involve surprisingly large or 
slow generated code.  This is one of the things many low-level C 
programmers dislike about C++ - it's too easy to generate a lot of 
object code for statements that look simple, and it becomes hard to keep 
an overview of how your code is actually implemented.  I am not saying 
this is a bad thing at all - just that it is something to be careful 
about, especially in documentation.

Will it be possible for people to define their own memory spaces with 
access functions?  For example, could they define a memory space for an 
external SPI eeprom?  That would multiply both the advantages and 
disadvantages mentioned above.

Having 24-bit pointers for directly accessing all the flash space on 
larger devices would be very nice.  But it is also important to have 
subspaces that are accessible with 16-bit pointers (or possibly even 
8-bit pointers?).  It is often the case that most of your flash data, 
and all your pointed-to functions, could fit within a 64K block of 
flash.  It must be possible to arrange for this - uses of the mega256 
should not have to pay the price of 24-bit pointers unless they really 
are using the full range.

It may be possible here to borrow ideas (and even code) from the "sdata" 
and "sconst" sections and addressing used on bigger RISC devices such as 
the PowerPC.  Smaller constant data is placed within a single 64K 
segment so that it can be accessed using 16-bit offsets from a base 
pointer - gcc therefore has support for automatically dividing up and 
segmenting constants (and variables) dependent on their size.


Another nice possibility that memory spaces opens up is for universal 
pointers - a 32-bit pointer with the first byte determining the memory 
space.  Such pointers would obviously be less efficient than 
memory-space specific pointers, but could be useful nonetheless.


There is a lot to look forward to in gcc 4.5 - and I'm sure a lot of 
work involved.  Personally, I'm waiting eagerly for link-time 
optimisation support.  The -fwhole-program and --combine flags do a 
reasonable job, but with LTO it will be a lot more streamlined, and 
libraries can be included in the link-time optimisation.  It should also 
work for C++, unlike --combine.

mvh.,

David