[CentOS] Re: 32/48-bit virtual addressing in 20/32/36/52-bit physical addressing -- WAS: Memory Models and Multi/Virtual-Cores

[Maciej Żenczykowski]

> 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.