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