How do you find the instruction alignment when disassembling

[matsondawson]

How do disassemblers normally do this?

[xlar54]

How do disassemblers normally do this?

Wouldnt they just ask for the starting address and disassemble from there? I dont think a disassembler could know how to align it properly without help.

[Mike]

With the exception of a few $x2 opcodes, most byte values are executable instructions on the 65xx. When you disassemble from a random address within code you've got a ~50% chance, that you don't start disassembly from an instruction byte, but rather from its operand field(s).

Depending upon bad luck, you easily can get a bunch of half a dozen undocumented instructions, until the disassembler aligns to the correct instruction stream.

If I see that, I usually retreat 1 or 2 bytes, and judge whether these instructions make more sense.

A disassembler, which doesn't show undocumented opcodes, usually fares better in this regard, as it flags them as '???' and tries again from the next byte, and then 'snaps in' to the right alignment earlier.

[ruud]

How do disassemblers normally do this?

My self written disassembler cheks what kind of instruction it is. In case of a branch it remembers this place. In case of a jump, it starts dissassembling from the new address. In case of a subroutine, it disassembles the subroutine and continues after the original JSR instruction. A RTS or an illegal instruction stops the disassembling. It now checks the list with branches and starts there. If this list is empty, it completely stops.

Known problems:
- branches there that are 'always' braches: there is a risk that the code behind this branch is data and not instruction code.
- indirect jumps: it is a disassembler, not an emulator. So if the used address isn't ROM, the disassembler has no idea where to jump too and stops here as well.

A user can create a file that can give more info to the disassembler like 'this part of the file is known as data/program' or 'this part contains vectors/a jump table'.