Re: [hatari-devel] Debugger: instruction at PC

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On keskiviikko 05 maaliskuu 2014, Miro Kropáček wrote:
> I'm not going to argue with that, I'm just curious whether it wouldn't be
> more useful to show (although not processed) next instruction. If
> 'disasm' can do that, I'm pretty sure 'cpureg', 'next' & friends can do
> that too.

Now I'm confused.  "disasm" and "cpureg" do show the same address:
------------
> r
D0: 00fc4102 D1: 00000001 D2: 000002db D3: 00000003 
....
00fc3474: 6108 51ca fffc 1341 0002 BSR.B #$00000008 == 00fc347e
next PC: 00fc3476
> d
$fc3474 : 6108                                 bsr.s     $fc347e
....
------------

Why do you think they show different address?

And from what you concluded that "cpureg" shows already executed
instruction and not one that's going to be executed next?

(I checked the code for all CPU emulation cores (about half a dozen
as there's old UAE & WinUAE and both emulate several CPU models),
and debugger is in each called as last step in the instruction
execution loop.)


If you were asking to show disassembly for next instruction when
when (re-)entering the debugger, does the attached patch what
you'd like to have?


> Btw, I've noticed that syntax / decoding of instructions in 'cpureg' and
> 'disasm' is sometimes different

By default, "disasm" uses external disassembler provided by Markus Fritze..
Whereas "cpureg" information is always output by UAE CPU core function.

If you want to, you can switch "disasm" to use UAE CPU core disassembler:
--------------------------------
> setopt --disasm help
Disassembly settings:
        uae - use CPU core internal disassembler which has better
              instruction support
        ext - use external disassembler which has nicer output
              and supports options below
        <bitmask> - disassembly output option flags
Flag values:
        1: no brackets around absolute addressing
        2: opcodes in small letters
        4: register names in small letters
        8: stack pointer as 'SP', not 'A7'
Current settings are:                                                                                     
        --disasm ext --disasm 15
--------------------------------

Most people prefer the external disassembler output though.


> -- for example I see 'addq.l #2,a7' in
> 'disasm' but 'cpureg' shows 'adda.l #2,a7' instead (yes, it makes things
> even more confusing because then I have really no clue what instruction
> is going to be processed at the first glance).

What "cpureg" shows should be correct, as it should be what
instruction CPU emulation core is going to emulate. :-)

Was "adda.l" the correct interpretation?

If you see external disassembler reporting wrong instruction,
please report the exact opcode, what instruction it should be
and what Markus' disassembler claimed it to be.


	- Eero

diff -r d357cecf4a86 src/debug/debugInfo.c
--- a/src/debug/debugInfo.c	Wed Mar 05 23:04:49 2014 +0200
+++ b/src/debug/debugInfo.c	Wed Mar 05 23:16:45 2014 +0200
@@ -35,6 +35,8 @@
 #include "vdi.h"
 #include "video.h"
 #include "xbios.h"
+#include "newcpu.h"
+#include "68kDisass.h"
 
 
 /* ------------------------------------------------------------------
@@ -848,13 +850,17 @@
 static void DebugInfo_Default(Uint32 dummy)
 {
 	int hbl, fcycles, lcycles;
+        uaecptr nextpc, pc = M68000_GetPC();
 	Video_GetPosition(&fcycles, &hbl, &lcycles);
+
 	fprintf(stderr, "\nCPU=$%x, VBL=%d, FrameCycles=%d, HBL=%d, LineCycles=%d, DSP=",
-		M68000_GetPC(), nVBLs, fcycles, hbl, lcycles);
+		pc, nVBLs, fcycles, hbl, lcycles);
 	if (bDspEnabled)
 		fprintf(stderr, "$%x\n", DSP_GetPC());
 	else
 		fprintf(stderr, "N/A\n");
+
+	Disasm(stderr, pc, &nextpc, 1);
 }
 
 static const struct {