The one problem with interpreters (like VIM) is that they are slow.
In fact, VIM used about 400 instructions to interpret a single instruction. So your program ran 400 times slower than normal.
The early PCs and clones were running 8088 chips at 4.77Mhz. Since they weren't all that efficent (not like the single clock instructions of modern chips), you got less than 1 million instructions per second (MIPS). So, at it's fastest, your 1MIPS program was running at
1000000 / 400 = 2500 instructions per second
Yah, it was slow.
This meant that all sorts of tricks were used to get any little bit of speed out of it that you could.
One of the biggest tasks of the interpreter was instruction decoding. Taking a byte stream like
A3 34 12
and determinging that this was the instruction
MOV [1234],AX
If you work with this for a while, you realize that you are much better off if you have two versions of the instruction decoder:
1) produces readable strings and computer instructions
2) just produces computer instructions
Most of the interpreters processing will be internal. You are not (usually) going to be watching every instruction. If you don't produce strings for the user (case 2), it is much faster.
If you are going to be producing strings for the user (for example, tracing a critical code section), you are not going to care (in general) how fast the routine is (the user can't keep up with the computer).
So, you trade code space for speed. A common trade-off.
You just have to be VERY SURE that both decoders are "in sync" so you can switch between them without anything breaking (or interpreting instructions incorrectly...)
Wednesday, October 28, 2009
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
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).
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
would write to location 1234, VIM will stop before the instruction executed and trashed memory.)
MOV BYTE PTR [SI],AL
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).
Friday, October 23, 2009
Personal computing history (part 1)
A long time ago, I wrote a lot of assembly language. I got very good at it.
Some years later, I was working for a company that did educational software. Back in the mid-80's a lot of PC software was copy protected. This was a major pain for us, as we had a $2000 program (back in the 80's this was even more of a painful cost than it would be now...) that broke when used on a faster (back then, 80286) machine.
So, my boss, knowing how good I was a low-level stuff, asked me to break the copy protection. No DMCA back then, I was free as a bird...
So, I started digging into the program with DEBUG. And taking notes...
After about 10 pages of scatterd notes with cryptic values written on them, I though to myself "Why am I doing this? I have a computer!" and so VIM was born. A month of effort got the basics working, and the copy protection was toast.
...to be continued...
Some years later, I was working for a company that did educational software. Back in the mid-80's a lot of PC software was copy protected. This was a major pain for us, as we had a $2000 program (back in the 80's this was even more of a painful cost than it would be now...) that broke when used on a faster (back then, 80286) machine.
So, my boss, knowing how good I was a low-level stuff, asked me to break the copy protection. No DMCA back then, I was free as a bird...
So, I started digging into the program with DEBUG. And taking notes...
After about 10 pages of scatterd notes with cryptic values written on them, I though to myself "Why am I doing this? I have a computer!" and so VIM was born. A month of effort got the basics working, and the copy protection was toast.
...to be continued...
Wednesday, October 21, 2009
Disk Rot...
Well, despite my warnings to others about software vanishing and keeping "old bits" around, I find that I've been bitten...
I'm doing some cleaning in the computer room (getting rid of old junk), and looked in a CD wallet that contains archives of my development work. The disks are succumbing to disk rot -- when I opened the sleeves in the wallet, they took the aluminum layer with them. Oops...
I think this was an interaction between that particular brand of CD and the plastic of the disk sleeve, since other CDs in the same wallet are fine.
Fortunately, I made multiple copies. On CD's from different companies. Stored in different locations and methods (CD wallets vs jewel cases).
I haven't lost anything, but that's just because I'm paranoid about such things. But not everyone is...
I'm doing some cleaning in the computer room (getting rid of old junk), and looked in a CD wallet that contains archives of my development work. The disks are succumbing to disk rot -- when I opened the sleeves in the wallet, they took the aluminum layer with them. Oops...
I think this was an interaction between that particular brand of CD and the plastic of the disk sleeve, since other CDs in the same wallet are fine.
Fortunately, I made multiple copies. On CD's from different companies. Stored in different locations and methods (CD wallets vs jewel cases).
I haven't lost anything, but that's just because I'm paranoid about such things. But not everyone is...
Monday, October 19, 2009
Back to work...
no, not you. Me.
About a week and a half ago I received an email from someone who sent me the source to Intel's AEDIT (of which SEE, the editor that came with DeSmet-C, is a clone). He is setting up a website about SEE, and both wanted me to have the AEDIT source (written in PL/M) and to have me "tidy-up" the DeSmet C pages in advance of being spidered by search engines for the new page.
So, this finally got me to get off my duff and post the DeSmet 2.51 C88 reconstruction I had done.
Though, if anyone wants to make a better DeSmet C page, I won't say no...
Also, I've started back in on the 2.51 GEN reconstruction I had started and not finished. This, as I anticipated, is more complex than the C88 reconstruction, as GEN had undergone more changes, both to support "large case" (i.e. large memory model) and to support direct generation of object code (no intermediate assembly language file).
I'm between 1/3 and 1/2 finsished, and plowing through. It's a bit worrysome, though, that I have several functions that I have yet to discover names for. This is probably due to routines that were subsumed by other functions, but it will mean that I have to "guess" names and code structure, which will make the reconstruction less useable. Hopefully I'll find the equivalent later code...
About a week and a half ago I received an email from someone who sent me the source to Intel's AEDIT (of which SEE, the editor that came with DeSmet-C, is a clone). He is setting up a website about SEE, and both wanted me to have the AEDIT source (written in PL/M) and to have me "tidy-up" the DeSmet C pages in advance of being spidered by search engines for the new page.
So, this finally got me to get off my duff and post the DeSmet 2.51 C88 reconstruction I had done.
Though, if anyone wants to make a better DeSmet C page, I won't say no...
Also, I've started back in on the 2.51 GEN reconstruction I had started and not finished. This, as I anticipated, is more complex than the C88 reconstruction, as GEN had undergone more changes, both to support "large case" (i.e. large memory model) and to support direct generation of object code (no intermediate assembly language file).
I'm between 1/3 and 1/2 finsished, and plowing through. It's a bit worrysome, though, that I have several functions that I have yet to discover names for. This is probably due to routines that were subsumed by other functions, but it will mean that I have to "guess" names and code structure, which will make the reconstruction less useable. Hopefully I'll find the equivalent later code...
Monday, October 12, 2009
It's loose!
The reconstructed DeSmet C v2.51 source, that is.
It only took me from January 2009 to now to do it...
It only took me from January 2009 to now to do it...
Friday, October 9, 2009
Easter Eggs, part 2...
Easter Eggs can also be in some surprising places. Like computer chips...
Known as Chip Art, these are microscopic doodles put in chip for fun (or copyright purposes, as described in the above wikipedia article).
Some of it is crude, some wonderfully detailed, all of it fascinating.
Check out Molecular Expressions and Chipworks and see if you really know what's inside your computer...
Known as Chip Art, these are microscopic doodles put in chip for fun (or copyright purposes, as described in the above wikipedia article).
Some of it is crude, some wonderfully detailed, all of it fascinating.
Check out Molecular Expressions and Chipworks and see if you really know what's inside your computer...
Thursday, October 8, 2009
Easter Eggs!
OK, not the kind you eat. It's the wrong time of year for that.
But, hidden "goodies" in film, software, TV, or whatnot are called easter eggs.
A common example is a hidden menu selection on a DVD. If you find the right button combination, you are taken to the "hidden" content (commonly a making-of feature or some such).
Another common easter egg is a hidden joke or reference. For example, in LOST, "the numbers" often show up in unexpected places, such as the numbers on police cars in a parking lot.
If you're interested in such things, check out The Easter Egg Archive.
But, hidden "goodies" in film, software, TV, or whatnot are called easter eggs.
A common example is a hidden menu selection on a DVD. If you find the right button combination, you are taken to the "hidden" content (commonly a making-of feature or some such).
Another common easter egg is a hidden joke or reference. For example, in LOST, "the numbers" often show up in unexpected places, such as the numbers on police cars in a parking lot.
If you're interested in such things, check out The Easter Egg Archive.
Tuesday, October 6, 2009
Now with more Fiber!
Subscribe to:
Posts (Atom)