One of the more painful things I had to debug with machine code. Tricks
I used can be seen in ex10.subx:
- printing argv[1] in various places
- printing a single 'X' in various places to count how many times we get
to different instructions
- exiting with the current value of EAX in various places
I repeatedly went down the wrong trail in several ways:
- forgetting that the problem lay in native runs, and accidentally switching
to subx runs during debugging.
- forgetting to pass commandline args, because ex10 doesn't check its argv
- writing the wrong comment for an instruction, and then miscalculating
the set of registers that need to be saved.
- forgetting that syscalls clobber EAX.
Debugging native runs is hard, because you have to write non-trivial code
to instrument the binary, and instrumentation can itself be buggy.
When we finally tracked it down, I recognized the problem immediately.
I'd meant to confirm the behavior of opcode 8a against bare metal, and
then forgot.
In any case, opcode 8a was inconsistent with 88. Sloppy.
Streamline the factorial function; we don't need to save a stack variable
into a register before operating on it. All instructions can take a stack
variable directly.
In the process we found two bugs:
a) Opcode f7 was not implemented correctly. It was internally consistent
but I'd never validated it against a natively running program. Turns out
it encodes multiple instructions, not just 'not'.
b) The way we look up imm32 operands was sometimes reading them before
disp8/disp32 operands.
The new example ex9 doesn't yet work natively.
In the process I've emulated the kernel's role in providing args, implemented
a couple of instructions acting on 8-bit operands (useful for ASCII string
operations), and begun the start of the standard library (ascii_length
is the same as strlen).
At the level of SubX we're just only going to support ASCII.
