|Re: [hatari-devel] Little disassembler bug ?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 07/10/2012 21:57, Laurent Sallafranque a écrit :
I think Nicolas wanted to keep the new core Winuae disassembler, but I
don't remember why.
having the original winuae disassembler available can be useful for
debugging purpose, especially with all the changes going on recently in
But even if they sometimes use slightly different notation, they should
give the same result, else a bug can be hidding somewhere. Especially in
that case, it seems something was broken in the winuae disassembler
recently (or maybe it was already broken in winuae)
Le 07/10/2012 21:41, Eero Tamminen a écrit :
On sunnuntai 07 lokakuu 2012, Laurent Sallafranque wrote:
While debugging something, I've noticed what I think is a little bug in
In my code, I have
With the (d) command, I read the correct opcode :
$05d9a4 : 4c01 0000 mulu.l d1,d0
When I activate cpu_disasm, I read :
0005D9A4 4c01 0000 MULL.L #$0000,D1
The result of the mul seems correct in d0.l after the mulu.l,
but the disassembled instruction seems wrong.
I assume this is with the WinUAE CPU core.
You need to change lines like this in its newcpu.c file:
m68k_disasm(stderr, m68k_getpc (), NULL, 1);
To look like this:
Disasm(stderr, m68k_getpc (), NULL, 1, DISASM_ENGINE_EXT);
I.e. instead of using the CPU core builtin disassembler,
use the disassembler contributed by Markus Fritze as
the old UAE core nowadays does.
Or is there some good reason why WinUAE core is using
its own disassembler?