superfury wrote:Why is the PG(Paging Enable) bit of the 80386 CR0 register at bit position 31? I understand that placing it at bits 15-0 will cause compatibility problems with old software, like data storage in the unused bits at 80286 software(the undefined bits, if present at all). But even so, they could have just used bit 16 as the paging enable bit? That leaves compatibility with the 80286 and easy upward compatibility with new bits on newer processors? Or is this because it can simply be tested by a JS/JNS (Jump if Sign bit (Not) set) after a simple AND with 0xFFFFFFFF or TEST instruction?
The 386 was designed by the same people as the 286, so why they shouldn't have used previously undefined bits ?
I mean, they were undefined, after all. The designers can't take reponsibility for the work of other developers who tweaked
their software in an odd fashion. Compatibility is only certain if the official programming guidelines are beeing respected.
Also, I think there were some over-optimized 486 games around at the time, which had to be patched to work on 586 or later CPUs, because
they relied on inofficial 486 behavior. Another explanation for PG at pos. 31 is, that these people wanted to separate 16bit/32bit mode a little bit more.
By the way, is it possible to use the paging unit from 16bit protected mode (on 386) ?
Please excuse my ignorance. I know, this is probably a silly question, but I never thought about this. I would be interesting to know, though.
Imagine a 16bit operating system, like OS/2 1.x, had the ability to use it when running on a +386 machine.
Azarien wrote:
I don't. 😀
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
//My video channel//