[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: [avr-gcc-list] Re: Why are we using EICALL and EIJMP for AVR256?
Date: Fri, 18 Dec 2009 09:33:13 +0100
User-agent: Thunderbird (Windows/20090812)

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.


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]