[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-chat] far addresses
From: |
Bob von Knobloch |
Subject: |
Re: [avr-chat] far addresses |
Date: |
Tue, 29 Aug 2017 11:54:24 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 |
On 25/08/17 16:31, Rolf Pfister wrote:
Am 25.08.2017 um 15:27 schrieb Bob von Knobloch:
Well, the problem is that the compiler doesn't appear to return the correct
address for constants (even when only the lower 16bits are examined) when
accessing objects above 64k.
It must be capable internally, I have code running there.
Code example, compiler version?
If you think its a compiler bug, maybe it could be helpful to
look at the created assembler code.
Rolf
_______________________________________________
AVR-chat mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/avr-chat
Hi Rolf,
Compiler is:
avr-gcc (AVR_8_bit_GNU_Toolchain_3.5.0_1662) 4.9.2
code is like:
const char teststring[] PROGMEM = "some text"; // Loaded with a
SECTION statement and a linker map at 0x01b000 (high memory) (and checked that it really
is there)
hex32out(teststring); // Prints the hex value
of the address of teststring
result: 00007187 // No relation to the
address
Anyway, Jörg Wünsch has commented somewhere that all such strings should be put
into low memory, so I think this is an indication that the compiler cannot be
used this way. I wouldn't call it a bug as the compiler is constructed for
processors with a 16-bit address space. Just that AVR have extended it by using
special instructions that we probably can't expect the compiler to support.
I have reorganised my code so that all symbolically addressed objects reside
under 0x10000 and those above are numerically addressed (luckily I could do
this, originally I had otherwise planned).
Anyway thanks for replying and maybe this helps someone.
Cheers,
Bob
--
The Sun is out, the sky is blue, it's time to drive the MR2.
Re: [avr-chat] far addresses, Bob Paddock, 2017/08/31