Closed avrs-admin closed 2 years ago
Stefan Ernst
It is a bug of the disassembler. Opcode 0x9184 is actually "lpm r24, Z" (not Z+).
Elrond
After a second look, my try_asm example shows the disassembler problem.
I have rebuild binutils-avr 2.20-1 for my system, but the objdump-disassemble-error persists.
Unless someone else is quicker, I will try to submit a bug to binutils sometime soon.
Elrond
Okay, bug filed in binutils: http://sourceware.org/bugzilla/show_bug.cgi?id=10964
Can someone please threat the bug here appropiately?
Anitha Boyapati
Looks like the bug has been marked as 'invalid' and 'resolved' in binutils bugzilla. Is this still relevant ? Please comment.
Eric Weddington
Closing this bug as "Transferred" as it was transferred to Binutils bug #10964.
Sat 31 Oct 2009 09:46:15 PM CET
Affected version: Debian avr-libc 1:1.6.2.cvs20080610-2 Current CVS most likely also affected, as macro didn't change.
At least on the atmega8515 _LPMenhanced seems to modify Z, at least according to the disassembly.
include <avr/pgmspace.h>
include
void try(uint8_t p) { uint16_t addr = 0; uint8_t j; for (j = 0; j < 10; j++) { p = _LPMenhanced(addr); p++; addr++; } } void try_asm(void) { asm volatile( "lpm r18, Z+nt" "lpm r18, Znt" ::); }
avr-gcc -Wall -mmcu=atmega8515 -Os -g -DF_CPU=3686400 -c lpm-z-mod.c -o lpm-z-mod.o gives:
00000014:
14: 25 91 lpm r18, Z+
16: 24 91 lpm r18, Z+
18: 08 95 ret
Note the Z+.
Also note that the Z+ can be seen as a feature. The addr++ wouldn't be needed anymore. But providing this feature to C in a clean way doesn't look easy at all.
This issue was migrated from https://savannah.nongnu.org/bugs/?27893