3 ms·
> That doesn't sound like a hardware bug to me at all. It isn't. It's a rare case of a software bug being worked around in hardware. That alone makes it fasc
by munch117 4y ago
> That doesn't sound like a hardware bug to me at all.
It isn't. It's a rare case of a software bug being worked around in hardware. That alone makes it fascinating.
The natural way of handling it in software would be to disable interrupts temporarily while changing the stack segment and pointer. You could just say that software developers should do that, but there's a performance cost, and more importantly: The rare random failures from the software already out there that didn't do this, would give your precious new CPU a reputation for being unstable. Better to just make it work.
- cesarb 4y agoAs others have already noted: yes, software could disable interrupts temporarily while changing the stack segment and pointer, but on these processors, there's a second kind of interrupt ("non-maskable interrupt" aka NMI) which cannot be disabled. (Some machines using these processors have hardware to externally gate the NMI input to the processor, but disabling the NMI through these methods defeats the whole purpose of the NMI, which is being able to interrupt the processor even when it has disabled interrupts.)
- munch117 4y agoI saw those other 8087+NMI comments, but the 8087 is from 1980, and I thought this fix was older than that.
- anyfoo 4y agoThe 8087 just happened to be one particular source of NMIs because IBM decided to connect it to the 8086’s NMI line. NMIs can be used for many things. Without this fix, they’re breaking stuff, at least without another hideous hardware workaround.