> The i386 onward normalizes the 32-bit "physical address" from a 48-bit > "virtual address" by creating a two's complement from the 16-bit segment > (bits 20-35) plus the 32-bit offset (bits 0-31). This 48-bit virtual -> This was on the i386? Hell, in real mode the seg reg is still left shifted 4 bits (not 20). So it still takes up bits 4-19 with the offset in bits 0-31 (which requires fiddling to use anything outside the 0-15). This only gives a 32 bit physical address - not a 36 bit physical address. And protected mode doesn't help any (page table entries are 22bits (or 32 with bottom 10 being zero) + 32 bit offset - with wrap - gives 32bits only again) > 32-bit "normalizing" is radically speed up in the i486 TLB over the i386 > (which does not have a TLB). If the two's complement is greater than > bit 31 (32-bit), then an overflow, exception, etc... occurs. There is > no A36 "hack" like there was for 8086/8088 though. there were no A32-A35 lines... and overflows were I believe silently ignored (wrapped) > PAE is mode in the Pentium Pro onward, supported in GTL+, that uses > the "4-bit overhang" (bits 32-35) of the 16-bit segment register to > address beyond 4GiB. This would be, in 8086/8088 terminology, an A32- > A35 hack. But can only do so in a way that pages into under 32-bit. > This is known as PAE36 -- because it is a 36-bit processor address > extensions (PAE) model, not a linear address access above 32-bit. ok, this I don't know about, but using the seg register to store addresses seems very highly protected mode incompatible... I would really really expect the topmost 4 bits in PAE36 to be taken from a special dedicated external lookup table (with 8 7bit entries) which is only available in PAE36 procs. Changing entries in this lookup table (which given a 32bit address, would use the top 3 bits to find a 7bit entry to replace the top 3bits giving a 36bit physical address) would require flushing large parts of the cache and would thus cause a performance hit - plus seeing these 512MB 'pages' would make memory management a pain. > PAE in x86-64 still uses the 48-bit virtual addressing approach. The > name "Long Mode" comes from the fact that instead of creating a two's > complement of overlapping bits, the 16-bit segment and 32-bit offset are > connected "Long" MSB of offset against the LSB of the register. So now > 48-bit virtual addresses are actually 48-bit wide, not "normalized" to > 32-bit or, using PAE (36-bit), 36-bit. Are we sure about this? x86-64 has 64bit registers - can't it just use the lower 48bits of a 64bit reg to store pointers? Why make life a pain with splitting pointers into two pieces? And how would they in the future intend to support full 64bit? will have to read up on this... Cheers, MaZe.