2023-01-17

The immediate assembler implementation of lDebug has progressed a lot. From an experimental feature with a lot of debugging and very little safeguards, it can now run most instructions without fail.

Calls can be traced into or proceeded past. Software interrupts are always proceeded past.

All instructions with an implied or explicit CS or IP operand are handled to act as intended. The branches (including jcc, loop, jmp, call, ret) are mostly simulated. Likewise push cs and push ds, as well as mov with cs or ds operand. A cs: segment override prefix is replaced by a ds: override and ds is temporarily overwritten with the value in the debuggee's cs (which differs from the internal immseg or immsel of the debugger which is the true cs of the immasm-assembled instruction).

The immasm code mostly can be written to the lDEBUG_CODE2 section if dual code is enabled. This turned out to be tedious because the assembler doesn't warn or error out when a call instruction tries to near call a label in another section. The code that is written to lDEBUG_CODE2 comes out to about 2 KiB.

The immediate assembler also got documented in the manual.

The dispatcher in cmd3 now allows a plain dot (followed by an EOL) to be handled as a no-op, even if _IMMASM is disabled. This is intended so that a plain dot line can always be entered, including when in assemble or register/variable write mode.

The immasm was also adjusted so its disasm call will not generally repeat disassembly. This is important especially when the NEC disassembly repeat rules are in effect, as they would cause the disassembler to repeat after any mov with a segreg operand as well as pop ds and pop es. It is important for immasm to disassemble just the one instruction, eg mov ds, word [cs:1234], so as to correctly detect the use of CS as operand or prefix.

Something unrelated to immasm is that the disassembly of int software interrupt calls was changed so it will depict 6 bytes of stack usage in 86 Mode and under 16-bit DPMI (regardless the CS bitness), and 12 bytes of stack usage under 32-bit DPMI (again regardless the CS bitness).

There are two dosemu2 bugs that need to be handled yet. I will have to compile a recent dosemu2 revision to test against however.