Re: [avr-gcc-list] avr-gcc 3.4.3 confused about function pointers

[Joerg Wunsch]

Björn Haase <address@hidden> wrote:

> IUUC, GCC itself only works with byte addresses. For Ram as well as
> for program memory.

Well, this doesn't appear to be the case here.  If the function
address is used without performing any calculation on it in the same
block, the compiler inserts the pm() address operators, and
effectively stores the word address inside the function pointer.  That
makes sense, as on devices with more than 64 KB (but <= 128 KB) of
flash, this allows a 16-bit function pointer to be used.  The ICALL
then simply pulls the function pointer out of its location, can calls
it.

However, if there's some address calculation done within the same
block, GCC gets confused about it.  Obviously, the address calculation
is done at byte level (which makes sense), but it then optimizes the
calculation together with the already `cached' function address, and
tries to re-use the cached address to store it into the function
pointer.  However, as there was no pm() operator applied previously,
this will now store a byte address into the function pointer.  Thus,
the ICALL will then call the wrong address.

Of course, this entire construction is highly questionable, and on the
ATmega128, the code would completely breaks for functions above 64 KB
of ROM as the char * in my example cannot be represented in a 16-bit
variable anymore.  Anyway, I think the compiler bug is that it must
not try to cache a function pointer address for any kind of address
computation.

Probably it would make more sense to leave all pointers at byte level
(including function pointers), and then perform the shifting right
before the ICALL instead.  This will require function pointers larger
than 16 bits for any device with more than 64 KB of ROM though, which
is not implementable using the current avr1/2/3/4/5 scheme, as an avr5
classification doesn't say whether the device has more than 64 KB of
ROM or not.  OTOH, perhaps such a distinction needs to be implemented
for full ATmega256x support anyway?

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)