On Mon, 2006-05-15 at 12:02 -0400, Jerry Feldman wrote:
Bryan, I do not see any reference to PAE 52-bit in the AMD 64 Architecture programmer's manual. Can you point me at a reference to this.
Processor Address Extensions (PAE). It's all over the first two AMD programmer manuals. Read the early tables on the different modes the AMD x86-64 processors support. You'll see the following ... x86-64 implements a 7-layer model using 52-bit registers with 48-bit flat addressing (so it's compatible with the 16-bit segement + 32-bit offset registers of the i486 TLB, which is capable of 48-bit virtual addressing) on a 40-bit capable physical platform (the 40-bit limitation comes from the core design of the original Athlon, based on the 40-bit interconnect of the Digital Alpha EV6 platform). It is compatible with legacy Intel Processor Address Extensions using 36-bit registers in 32-bit addressing model on a 36-bit capable physical platform (using paging). AMD _only_ covers how to enable x86-64 "Long Mode" in the kernel with the resulting 52/48/40-bit model. It also talks about how x86-64 "Long Mode" is able to run newer 48-bit as well as old 32-bit flat memory model programs. AMD mentioned a "flat 64-bit" model is a future consideration. But considering it breaks compatibility with the i486 TLB, so you won't be able to run 32-bit or PAE 36-bit programs, AMD has left it for later. It's very likely that the next AMD (as well as Intel) designs with the 'Visor virtual approaches will implement an internal address model with a "flat 64-bit" model, but then provide 20-bit (Virtual86), 24-bit (Protected286), 32-bit (Protected 386/i486 TLB), PAE 36-bit (Pentium Pro GTL+ 64GB) and 48-bit/PAE 52-bit (x86-64) virtual machine "instances" -- overcoming the 48-bit 256TB memory limitation of the current 48-bit, PAE 52-bit approach (as well as the new CPU overcoming the 40-bit 1TB physical memory limitation of current Athlon 64 / Opteron) But the AMD x86-64 manual do _not_ cover the more complex issues of memory models in general. It does _not_, because it can_not_, discuss and solve how 32-bit flat memory model programs (or those that are also enable of PAE 36-bit for up to 64GB of RAM) can run 48-bit flat memory (when the kernel uses PAE 52-bit addressing registers). You'll _also_ find _any_ Intel manuals on IA-32 does the same with regard to handling programs other memory models for the 8086 or 80286. The Intel IA-32 manuals only talk about how Protected386, Protected286, Real86 and Virtual86 modes work -- _not_ how you solve the greater issue of programs/libraries/plug-ins of _different_ memory models using each other. Solving how programs of different memory models dynamically inter-operate with each other has _nothing_ to do with the processor. The processor can only provide the capability so both can _co-exist_, but _not_ necessarily so they work with each other. This is a problem that plagues _all_ programs, libraries and plug-ins on _all_ OSes, when their memory models differ. You want to read up on UNIX C libraries (e.g., GLibC and x86-64 as well as the POSIX/SUSv3 lib64/lib design) as well as Microsoft Windows on Windows (WoW). -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own