Who knows?

But bit 16 was later used for the WP (write-protect) flag in 486, so it certainly could be used for PG too.

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:

Who knows?

I don't. 😀

Jo22 wrote:

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.

Yes, this is entirely allowed. If it weren't, then Windows 3.x wouldn't be able to use virtual memory.

SarahWalker wrote:

Jo22 wrote:

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.

Yes, this is entirely allowed. If it weren't, then Windows 3.x wouldn't be able to use virtual memory.

Doesn't the 286 get exploited as well(by simulating paging using segment descriptors) to implement 286+ virtual memory? Up to 1GB virtual memory, apparently(on a 286, with 16MB physical memory)? How do they even get that 1GB virtual memory? Doesn't that depend on the harddisk? Hell, you could get 2TB of virtual memory with 32-bits of sector address(32-bit IDE out of 48-bits). Although the limit was 28-bits at the time(ATA-1), but it could still be put into the segment descriptor(up to 63 bits? 64-bits(8-byte) descriptor minus present bit?)?

Edit: calculating it manually: 8192 descriptors times 2 tables(GDT/LDT) times 64kB(maximum segment size) = 1GB RAM. So is that why the 80286 has the 1GB virtual memory limit? The total amount of descriptors limit the RAM in that case?