Menu
▾
▴
#53 bugfix for jmp/call opcode
Hi,
while writing a disassembler to the AVR architecture and verifying it
against avra I found a bug in the opcode generation of the jmp and call
instructions in avra: bit 16 (0x10000) is not stored in bit 0 of the first
opcode word.
The effect is that a jmp $1aaaa is erroneously assembled as jmp
$0aaaa, but jmp $2aaaa is correctly assembled as jmp $2aaaa and so
on. Of course this only matters for cores with more than 128k program
flash.
Replacing the erroneous opcode mask 0x1000 by 0x10000 fixes the
bug. Here is the patch:
diff -Naur avra110.old/mnemonic.c avra110/mnemonic.c
--- avra110.old/mnemonic.c 2005-11-14 13:40:48.000000000
+0100
+++ avra110/mnemonic.c 2006-09-03 14:39:53.000000000 +0200
@@ -451,7 +451,7 @@
return(False);
if((i < 0) || (i > 4194303))
print_msg(pi, MSGTYPE_ERROR, "Address out of range (0
<= k <= 4194303)");
- opcode = ((i & 0x3e0000) >> 13) | ((i & 0x01000) >> 16);
+ opcode = ((i & 0x3e0000) >> 13) | ((i & 0x010000) >> 16);
opcode2 = i & 0xffff;
instruction_long = True;
}
Other than that I found only bugs in my disassembler. :-) The
assembler seems 100% OK (except for this patch).
(BTW: I did a complete from-scratch development of the disassembler
and verified the disassembler against avra by first disassembling all
possible AVR instructions, then assembling the disassembly using avra
and disassembling the hex file again. Both disassemblies are now the
same. Of course I can not find any missing instruction in my
disassembler this way. I plan to write a data flow analysis tool which
helps maintaining enormous amounts of assembler source code.)
Thanks for avra, it's great!
Kind regards,
Johannes Overmann (Johannes.Overmann@gmx.de)
Patch for mnemonic.c which fixes the jmp/call opcode generation
Logged In: YES
user_id=726755
Hi Johannes,
Thanks for the great work. I will add it to 1.1.0. Let us
know if you got a link to your disassembler where it can be
downloaded. I will add it to our README!
Tobias
Logged In: YES
user_id=726755
Fix added to 1.1.1