mov eax,cr0
inc ax ;sets bit 0, assuming it was clear
mov cr0,eax
dec ax ;clears bit 0
mov cr0,eax
"But that's cheating!", some might say - not really, how else would it be possible to even execute one instruction in protected mode, if those registers weren't already initialized to a sane state? CS at the very least has to be, so that you can execute a jump to the "proper" protected mode segment right after loading CR0.
I remember reading some documentation that even said you can load GDT either before or after the "switch" to protected mode, which would be even more impossible if that somehow required different segments already set up.
If you want to be pedantic, there also has to be a jump in there to clear the prefetch queue and make sure the CPU actually interprets code according to the new mode, instead of the one that was active when the instruction was fetched and decoded. But that first jump can - and according to some Intel manuals, must! - actually be a near jump, staying in the same code segment at least for the moment. Since a lot of protected mode init code gets this wrong however, they had to keep support for a far jump as the first instruction as well, probably making the microcode for that instruction slower than it could have otherwise been.
(To enter "unreal mode", of course you do also need a GDT, but it doesn't need to have any descriptors other than one for the flat 4G data segment)
The previous submission was ~1 year ago in https://news.ycombinator.com/item?id=39292990, although it did not spark significant discussion threads.
Also, here are the related articles from this series:
* https://blogsystem5.substack.com/p/from-0-to-1-mb-in-dos
* https://blogsystem5.substack.com/p/running-gnu-on-dos-with-d...
anthk•9mo ago
- Assembly language of the 80x86'es
- 8086, 80286 and 80386 microprocessors
- 386 and486 Advanced microprocessors / Introduction to the Pentium and Pentium Pro
On DOS and DPMI, DOSEmu ran DOS (FreeDOS, DRDOS and MSDOS) and it was much faster than DOSBox as it was something closer to Wine than full emulation, and it had a setting for DPMI too. DN3D ran in real time on machines where DOSBox would halt to it knees.