Oldskooler Ramblings

That was the IM I got from a “friend” who shall remain “nameless” who was “unhappy” with the state of my “blog”. Fine, so I’ll post something, but for the record I have had excuses for not posting the last four weeks:

• Not losing weight, so that alone is depressing
• Went to GDC and was very sick the entire damn time (although I did have some good experiences; more on that later)
• Still sick 2.5 weeks later (yes, I’m seeing a doctor)
• Weathered a layoff storm at work, sometimes violent, sometimes petty
• Child problems at school

etc. etc. My life is actually quite privileged, and it sounds utterly ridiculous to complain, but I am human, which means I’m damaged, and this stuff affects me. I know it’s irrational. I’m sorry.

So, until I can lose some weight or report on some other stuff that is actually interesting to someone, I’m going to Post Something Dammit. Today’s PSD is on the topic of: 8088 CPU bugs. It’s time for some st00pid k0mp00ter history! Yes, the 8088 had bugs in the first iterations. Forget the Pentium FDIV bug; they’ve all had issues from day one :-) Two of the bugs were caught by Intel in 1982-ish, but not until 200,000 IBM PCs were sold. The third was fixed in the 80186.

The first two bugs involved interrupts and the stack. The first bug was that a MOV to SS (the stack segment) did not disable interrupts for the next instruction, meaning that you could get an interrupt in the middle. This is bad, because the interrupt will try to set up it’s own stack (something you were trying to do with the MOV SS!) and the stack is unlikely to recover, taking the machine with it. The workaround was this:


CLI
MOV SS,DX
MOV SP,AX
STI


ie. disable interrupts before you do the switch, then re-enable them when done. Which sucks, but is a good practice that I would imagine most people were doing anyway because they didn’t know that MOV SS,reg was a special case that was supposed to disable interrupts. Hell, I didn’t even know that until I started researching the bug.

But not all was good in Intel land: If you didn’t know the state of the interrupt going in, then you were supposed to preserve it, like this:


PUSHF
POP BX
CLI
MOV SP,word ptr [my_stack]
MOV SS,word ptr [my_stack+2]
PUSH BX
POPF


…except there was a second bug in the original 8088 in the POPF opcode which meant that, even if the state was still CLI after the POPF, interrupts would still be enabled for a single cycle! Try tracking THAT bug down in your program! So the workaround, which is just st00pid, is to fake POPF using IRET. (BTW, the odds of this particular bug cropping up is somewhere in the neighborhood of 1 in 5 million, and only when you switch stacks, so it is such a longshot that I never bother in my own code.)

But wait, there’s more! There’s a third bug where, if you try to use a segment override on MOVS or LODS (ie. so you can attempt to use something other than DS as the source) and an interrupt fires off during, say, a REP MOVSW, it stores the wrong return address. This was fixed in the 80186… I think. Not sure. I’m not sure that behavior is even officially documented so I’ve never had the urge to try it.