Monday, October 26, 2009

Personal computing history (part 2)

So, why was this such a big deal?

Well, the best debugger is an interpreter. VIM stands for "VIrtual Machine", and is an interpreter for 8086 machine code.

With it's own memory space, so changing something important (like trashing the interrupt vector table) wouldn't crash the real machine.

Simulated periphirals (like interrupt controllers) and access to the actual machine hardware (keyboard, disk drive) so that it could do real-world simulations (like booting and running a different operating system the the one running VIM). And the ability to turn hardware access off, so you could protect your system from malicious software.

Breakpoint on data access, so you can see how a stray memory pointer is trashing your data.

Breakpoints were setup so that if executing an instruction would cause a breakpoint, the break occurred before that instruction executed (for example, if you wanted to see how memory location 1234 was being overwritten, you could set a breakpoint on 1234. Then, if executing the instruction

MOV BYTE PTR [SI],AL
would write to location 1234, VIM will stop before the instruction executed and trashed memory.)

VIM will also remember the last 2047 instructions executed, so you can figure out just how you got to this point.

Also, save/restore your debugging session to disk. So you can go home for the night and pick up where you left off in the morning. Or play "what if" on code execution, and go back to a known starting state any number of times.

So, I now had a tool that would let me do all sorts of neat stuff. And one that would become the basis for much of my work in the future (though I didn't know it at time time).

No comments: