Disassembling at specific address

[pvmm]

One of those things that is easier to do in the emulator than on the debugger. Let's say you have the following code at 0x100:

C3 12 0D, which translates to JP #0D12

But if you want the decoding to starting at the next byte (0x101), you get LD (DE),A and DEC C. Is there a way to tell the debugger were to start disassembling without setting the PC in the CPU registers window to point to that address or filling up previous bytes with NOPs until the instruction starts? Maybe the Goto... menu item could point to the start of a instruction, so I get different results if I go to address 0x101 instead of 0x100?

[m9710797]

I'm not sure I understand the question. I'll try to answer, but please clarify in case I missed your point.

In openMSX itself there are two commands to (help with) disassembling:

• The high-level command disasm [<addr>] [<lines>]: Without any arguments this indeed starts disassembling from the current PC, but you can easily pass any other address.
• The low-level command debug disasm [<addr>]: Again by default this takes the PC, but you can pass any address. This command only disassembles a single instruction. The result is a Tcl list. The first element of this list is the textual representation, the later elements are the opcode bytes (in hex). So from the length of this list you can derive the length (in bytes) of this instruction.

For more details see:

• help disasm
• help debug disasm

The disasm command is implemented as a Tcl script, and internally it uses debug disasm. It might be instructive to check that implementation: https://github.com/openMSX/openMSX/blob/master/share/scripts/_disasm.tcl#L126

[pvmm]

This issue is about the code view widget and how you can't easily change the address boundary where an instruction starts and where it ends. Let's say you have the following disassembled code in code view:

7FFA 11 11 11      ld        de, #1111
7FFD 11 11 11      ld        de, #1111
8000 FE 00         cp        #00

Then you change byte in 7FFA to 00 (nop), and when you visit the code in 0x8000 again, it is completely different:

7FFA 00             nop
7FFB 11 11 11       ld        de, #1111
7FFE 11 11 FE       ld        de, #fe11
8001 00             nop

because it is in a different address boundary. Maybe the code is non-continuous and somewhere there is a jump directly to 0x8000, which would consider the next instruction cp #00 and not nop nor ld de,#fe11, but there is no easy way to change the boundary in the debugger. My suggestion is that a CTRL+G to 0x8000 could be used to force the debugger to interpret the specified address as the start of the boundary and read the right address where cp #00 is again, but that doesn't work because the debugger considers that the address is already in memory and does nothing.

But maybe there is an disadvantage in doing that. What do you think? That's why this is a suggestion instead of a pull request.

[MBilderbeek]

The disasm command is implemented as a Tcl script, and internally it uses debug disasm. It might be instructive to check that implementation: https://github.com/openMSX/openMSX/blob/master/share/scripts/_disasm.tcl#L126

As far as I know, the disassembler is reimplemented in the debugger... see DasmTables.cpp and Dasm.cpp.

[m9710797]

Ah OK, now I understand (I think).

This is a general disassembler problem (for CPU architectures with variable-length instructions). I quickly checked how a few other disassembler deal with this. And as far as I could see they all just start disassembling from the first address in the window. And they have a command to set this first address. So indeed like the CTRL+G you suggested.

The only alternative I found was the disassembler found in "Compass". This allows to use the cursor up/down to scroll through the disassembler window. Normally this scrolls full instructions, but if you hold CTRL and then press up/down you instead scroll per byte. Personally I don't think this is a good fit for the openMSX-debugger. Your suggestion with CTRL-G should be sufficient.