3 ms·
Wow, there's _pages_ and _pages_ of programs which would have been seemingly broken because they forget to "sti" after having "cli". It was one of those things
by mfontani 6y ago
Wow, there's _pages_ and _pages_ of programs which would have been seemingly broken because they forget to "sti" after having "cli". It was one of those things we were taught to always, no matter what, do in high school -- one of those "do one thing, and always the inverse" - like push to stack, pop back from stack kind of thing.
Really odd to see those things "out there"!
- bcaa7f3a8bbc 6y agoYou missed its context. In real mode, the interrupt enable/disable status is controlled by the global CPU flag, in bit 9. If you saved the entire FLAGS register when interrupt was enabled with "pushf", and later you use "popf" to restore the flags, there's no reason to use "sti", since the interrupt bit was already restored, it was perfectly legal in real-mode DOS. However, in protected mode under an OS, it's unacceptable for a single program to disable interrupts of the entire CPU, so the global CPU interrupt flag is always enabled and controlled by the OS, but each program had its own virtual interrupt state controlled by "sti" and "cli", and cannot be changed by "pushf" and "popf" anymore. What actually happened: This problem was already recognized in the beginning, documentation contains multiple warnings and examples of correct code, but developers ignored all the warnings and instructions, continued misusing "popf" and doing it wrong in as many different ways as possible.
- mfontani 6y agoIt was a bit difficult to follow and the reasons behind why things failed weren't fully clear. I've also not written any asm in a couple decades... so, thank you very much for explaining this to me. It makes total sense now!