The 8088 processor in the first IBM PC had a bug that gave me some grief.<p>(The code below is likely to have bugs of its own - I wrote it from memory as an illustration of the CPU bug - and thanks to 'tlb' for catching an error in my first draft. I also left out the question of what data segment the various MOV instructions use for their memory references, as it isn't relevant to this CPU bug.)<p>If you needed to work in a different stack from the one you were currently running on, you might do something like this:<p><pre><code> mov saveSP, sp
mov sp, mySP
...
mov sp, saveSP
</code></pre>
This saves the original SP (Stack Pointer) register, loads it with your private value, and then restores SP when you are done.<p>Suppose you wanted to switch not only to your own stack <i>pointer</i> but also your own stack <i>segment</i>. With 16-bit registers you could only address 64KB at a time, and you would need to change a segment register to access memory outside that range.<p>So you would save, change, and restore both the SS (Stack Segment) and SP registers:<p><pre><code> mov saveSS, ss
mov saveSP, sp
mov ss, mySS
mov sp, mySP
...
mov ss, saveSS
mov sp, saveSP
</code></pre>
Now imagine that an interrupt triggered in between one of the changes to SS and the matching change to SP. The interrupt code would now be running on the <i>new</i> stack segment but the <i>old</i> stack pointer, corrupting memory and crashing.<p>Not to worry! Intel had your back. The documentation promised that after a MOV SS or POP SS, interrupts would automatically be disabled until the next instruction (the matching MOV SP or POP SP) completed.<p>But they kinda forgot to implement that feature. So if you followed the docs, you would have these very rare and intermittent crash bugs.<p>Word got around fairly soon, and the fix was simple enough, disable interrupts yourself around the paired instructions:<p><pre><code> mov saveSS, ss
mov saveSP, sp
cli
mov ss, mySS
mov sp, mySP
sti
...
cli
mov ss, saveSS
mov sp, saveSP
sti
</code></pre>
This still left you unprotected against NMI (Non-Maskable Interrupt), but by the time most of us built NMI switches for our IBM PC's, we'd also upgraded to newer CPUs with this bug fixed. It was only the earliest 8088s (and perhaps 8086s) that had the bug.