Re: [avr-libc-dev] [Bug #3184] XCALL resolved incorrectly in avr5/libc.a

[Marek Michalkiewicz]

On Fri, Apr 11, 2003 at 12:07:19PM +0200, Joerg Wunsch wrote:
> . the library compilation cannot decide whether the device supports
>   the ELPM instruction (not all avr5 devices do support it)

If all uses of ELPM are limited to gcrt1.S and include files, that
should be no big problem.  GCC itself does not use ELPM at all, and
puts "progmem" data at low addresses, avoiding the use of inefficient
24-bit pointers, and still leaving the upper 64K for executable code -
looks like a good compromise to me.

> . the assembler disallows absolute jump/call instructions for the
>   ATmega8 even though this device supports them (but doesn't require

Have you tested if the JMP/CALL opcodes work on a real ATmega8 chip?
If yes - OK, I can change the assembler to accept these opcodes...

>   them -- wouldn't your suggested change even cause absolute jump/call
>   to be used on the ATmega8 then?)

No, because for GCC, ATmega8 is not really considered "mega" :-)
(GCC used the "mega" == "more than 8K of program memory" convention
long before Atmel announced any plans for ATmega8/8515/8535...)

> . the library cannot decide whether the target device /must/ use
>   absolute call/jump (i. e., /this/ bug, #3184)

This should be solved now.  It went unnoticed for so long because
the C preprocessor considers the "FLASHEND > 0x2000" condition to
be false if FLASHEND is not defined, without any warning...

Marek