Wikipedia

Talk:Physical Address Extension/Archives/2015/August

< Talk:Physical Address Extension
Latest comment: 8 years ago by Jeh in topic PAE is A Processor Feature

PAE is A Processor Feature

Latest comment: 8 years ago20 comments4 people in discussion

Definitively, PAE is a processor feature, extending 32-bit instruction set to address more than 4GB Physical Memory. The quoted description is not strictly correct! In Intel document, PAE, is also used to reference to Page Address Extension mode.

Not strictly correct description, it is not an enhanced version of PAE, it is an enhanced version of paging schema for this new paging schema does not apply onto the Legacy 32-bit mode operation. In other words, no 32-bit linear address mapped on the 4-level paging... CopperQA (talk) 22:55, 18 September 2015 (UTC)

Regarding "page address extension" vs "physical address extension"

"CopperQA", I can find no support for your position. I don't know what Intel documents you're looking at. I notice you didn't give a link... but I will.

In the most recent Intel® 64 and IA-32 Architectures Software Developer’s Manual, downloadable here, the term "page address extension" flatly does not occur. But "physical address extension" does, 20 times.

Nor does this seem to be a recent change. Here is the 1999 version of a part of the same document, chapter 3, "System Programming". Again, the term "page address extension" does not occur. "Physical address extension" does (10 times).

You will also find that Microsoft calls it "physical address extension".

The Mindshare, Inc. book on Pentum Architecture: Tom Shanley's Pentium Pro and Pentium II System Architecture, which is widely recognized as authoritative, uses "physical address extension".

You're just wrong.

Google search: "page address extension" gives about 8,000 hits. For "physical address extension", about 150,000.

Personal note: I am aware that "Page ..." is a widely-understood alternate name, but appears to me to have no official standing. I prefer "Physical..." because, besides being the official name, it's more precise. "Page address extension" could be interpreted as referring to addresses of either physical or virtual pages, which of course would be incorrect. If the two terms had equal or nearly equal standing, even within an order of magnitude in terms of hit counts, I would still argue vehemently for WP's preferring "physical..." on that basis. But they don't have equal standing. Jeh (talk) 02:45, 19 September 2015 (UTC)

This is a typical way of explanation by Jeh, this section is talking about PAE is a processor feature, and an enhanced paging schema. But all his/her words are dealing with

,

trying best to use this as the reason or proof to get rid of the one who figures out his/her mistake. I do not think this reply would help to answer this section or improve the main article. CopperQA (talk) 03:02, 19 September 2015 (UTC)
I haven't gotten around to replying to your complaint about "enhanced paging schema". Jeh (talk) 04:28, 19 September 2015 (UTC)
Readers who are interested in the phrase page address extension (PAE) mode, please check page 18 of http://download.intel.com/support/processors/xeon/sb/309159.pdf CopperQA (talk) 03:16, 19 September 2015 (UTC)
Ok, you found an authoritative reference for the use of the term. Still, googling for { page address extension site:intel.com } yields only 11 hits. Change to "physical" and we get more than ten times that many. The Software Developer's Manual is still the more authoritative source, backed up by AMD, Microsoft, Mindshare, etc., so the article name should not change. But I have added the mention of this alternate name to the lede, with your link as a ref. Note that we already had a redirect from Page Address Extension, accordingly the term is bolded in the new text. Jeh (talk) 04:25, 19 September 2015 (UTC)
I have completely no ideas whether I should say thank you to Jeh, because I just mentioned, In Intel document, PAE', is also used to reference to Page Address Extension, without additional word around it. Wow, ridiculous! I wonder whether there would be some normal replies in the future? CopperQA (talk) 04:45, 19 September 2015 (UTC)
But you didn't give any reference for your claim, and given that I have at least fifteen years' worth of different versions of the Intel Software Developer's Manual and none of them have used "Page Address Extension", and neither have the other refs I already gave, your claim appeared unfounded. Jeh (talk) 06:41, 19 September 2015 (UTC)

Regarding "an enhanced version of PAE" vs ...

Round one

CopperQA, you wrote

"it is not an enhanced version of PAE, it is an enhanced version of paging schema"

But the "paging schema" it's an enhanced version of, is PAE! (If not, then what is it?)

It is very difficult for me to understand how anyone familiar with this material could say that x64's long mode address translation scheme is anything but an enhanced (or extended... whatever) version of PAE. Although the AMD x64 documentation never quite uses those exact words, it is rife with wording that supports it.

Furthermore, the AMD doc explicitly uses the term "PAE" in describing address translation in long mode.

AMD64 Architecture Programmer’s Manual, Volume 2: System Programming (June 2015 edition, available here) describes PAE first (section 5.2.3) then section 5.3, "Long-Mode Page Translation" describes address translation in long mode as a series of changes (i.e. extensions, enhancements) from the PAE scheme. i.e. Long mode address translation is not described as a completely separate scheme.

Specifically:

"The legacy x86 architecture provides support for translating 32-bit virtual addresses into 32-bit physical addresses (larger physical addresses, such as 36-bit or 40-bit addresses, are supported as a special mode). The AMD64 architecture enhances this support to allow translation of 64-bit virtual addresses into 52-bit physical addresses... (section 5.1)
"Figure 5-1 on page 119 shows an overview of the page-translation hierarchy used in long mode. Legacy mode paging uses a subset of this translation hierarchy..." If legacy mode uses a subset of long mode, then is it not valid to say that long mode address translation is a superset, i.e. an enhancement or extension, of legacy mode? This is a basic principle of set theory.
"PAE must be enabled before activating long mode." (5.1.3, also nearly-identical wording in 5.3)
"Long-mode page translation requires the use of physical-address extensions (PAE). Before activating long mode, PAE must be enabled by setting CR4.PAE to 1. Activating long mode before enabling PAE causes a general-protection exception (#GP) to occur." (5.3) In other words, you can't enable long mode without first enabling PAE; long mode does not eliminate the need to enable PAE.
In section 5.3, entitled "Long-Mode Page Translation": "The PAE-paging data structures support mapping of 64-bit virtual addresses into 52-bit physical addresses." (5.3) There it is! They explicitly call it PAE under long mode. Obviously they are not referring to legacy mode PAE here because there are no 64-bit addresses in legacy mode. There's just no wiggle room here.
"The AMD64 architecture enhances the page-directory-pointer entry (PDPE) by defining previously reserved bits for access and protection control. (5.3) Of course, what they're referring to is the PDPE as used under legacy mode PAE.
"A new translation table is added to PAE paging, called the page-map level-4 (PML4)." (5.3) "Adding to" is "enhancing" or "extending", no?
"Because PAE is always enabled in long mode..." (5.3) And there it is again.
"CR3 is expanded to 64 bits in long mode, allowing the PML4 table to be located anywhere in the 52-bit physical-address space..." (5.3.2) "Expanded to" is "enhancing", no?

(bolding in the above was added by me in all cases)

The index is also telling. All entries pertaining to long mode address translation appear as sub-entries of PAE, to wit: 

PAE paging ..................................................... 25, 122
  CR3 format ................................................... 46, 123
  CR3 format, long mode............................................. 130
  legacy mode ...................................................... 126
  long mode ........................................................ 131

In short, long mode address translation is always treated as a variant of PAE. It is never described as if it stands apart from PAE.

You also wrote "for this new paging schema does not apply onto the Legacy 32-bit mode operation." Of course it doesn't; why would it? Legacy mode is supposed to be an exact emulation of x86. Except: A 32-bit OS running in legacy mode is able to use 52-bit physical addresses! (That's in section 1.1.2.) Which did not exist on x86. So that aspect of the "new paging schema" does apply to legacy mode. As does the NX bit.

Your claim that "no 32-bit linear address [is] mapped on the 4-level paging..." is false. When you're in compatibility mode—for example, when you're running a 32-bit program under 64-bit Windows—the program is presenting 32-bit linear addresses, but CR3 still points to a PML4 rather than a PDPT, all four table levels are there, and the 32-bit linear addresses are most certainly translated via the four-level paging scheme. Granted, the offset into the PML4 will be zero, but the PML4 table must nevertheless be present. Therefore, 32-bit linear addresses are mapped via 4-level paging.

You are correct that this does not apply in legacy mode (which is how you'd be running with a 32-bit OS, and there would be no 64-bit linear addresses ever, and the page tables would always be two or three levels). But long mode and legacy mode are processor-wide, "either one or the other" things. If you're in legacy mode you're using PAE just as it was on x86 (except that physical addresses can now be 52 bits, and the NX bit exists and is enforced). If you're in long mode you're using the four-level page tables, which look just like the three-level tables under PAE but with another level added and 16 more bits of virtual address translated. I don't see how this makes address translation in long mode to be anything other than they "an enhanced version of PAE".

I'd go along with changing "enhanced" to "extended", but this looks to me to be merely change for the sake of change, a distinction without a difference.

I am certainly willing to hear from other interested editors on this question. But for myself, I see ample support for the existing text and no reasonable, let alone valid, argument against it. Jeh (talk) 06:41, 19 September 2015 (UTC)

Round two

PAE was first speaking to a IA-32 architecture processor, Pentium Pro exactly. Is the North Bridge in Athlon K10 and so many APUs are really North Bridge? OK, all your referrences are reasonable! But to the very nature of that thing, it is not an enhanced version of PAE at all, obviously and frankly, a real 64-bit processor does not need extending a 64-bit linear address into a 52-bit physical address, or else another IA-32 processor! — Preceding unsigned comment added by 119.53.110.56 (talk) 14:52, 20 September 2015 (UTC)
I see nothing at all compelling in the above. I have described extensively how long mode address translation is completely reasonably described as an enhancement of x86 PAE, and I gave ten references to the AMD doc that support that view.
By contrast, all you have written here amounts to "no, it's not, because it isn't; it can't be." You have given no rationale for that opinion, no references to authoritative sources that back up your opinion, no cogent rebuttals to any of the points I made... nothing. Just your denial. Furthermore, in all the months you've been beating this dead horse, nobody else has ever spoken up in agreement with you.
In particular, your claim that "a real 64-bit processor does not need extending a 64-bit linear address into a 52-bit physical address" can only be described as a bizarre wording (nobody ever said anything about "extending a linear address"). Or, if you actually meant "mapping" or "translating", then you are opining in flat denial of the facts; as you are directly contradicted by this from the AMD doc, which I quoted before:
"The PAE-paging data structures support mapping of 64-bit virtual addresses into 52-bit physical addresses."
And I have no idea what you mean in referring to "or else another IA-32 processor."
Frankly, your phraseology and your continued harping on this point - despite a huge number of replies along the same lines as the above - makes me suspect you just don't comprehend English well enough to understand that "enhanced version of PAE" is a completely correct description.
In any case, I consider your opinion well and thoroughly rebutted.
If no one else has anything to say in agreement with you, I think we should consider this matter closed and settled; so this phrasing will remain in the article. If you bring it up again you're just going to be pointed to this thread.
Verb. Sap.: Sometimes you don't get everything you want, no matter how much you think you're right. Jeh (talk) 03:21, 21 September 2015 (UTC)

Round three

emulation, definitively no! No matter instructions for x86 or x86-64 are directly executed thorough microarchitecture without emulation at all for all AMD64 processors, including K8, 10h, Bulldozer or even latest ZEN! For Intel processors with EM64T Enabled, we have no ideas whether there would be emulation, but for all Intel 64 processors (Core Microarchitecture and later) there is no emulation at all! — Preceding unsigned comment added by 119.53.110.56 (talk) 14:52, 20 September 2015 (UTC)
Granted that "emulation" sometimes means what you're referring to.. yes, instead of emulation I should have said "is supposed to act almost exactly like x86". I hope this little discovery of my imperfect choice of words brings you much joy. However this is irrelevant to the issue of "enhanced version of PAE" phrasing. Jeh (talk) 03:21, 21 September 2015 (UTC)
Sorry, I comprehend English, British English and American English; but I could comprehend your English! Frankly, description on wikipedia could not be used as a referrence in some formal situations. So correct or incorrect does not really matter! So one does not need to make up for one's own words. This is the last arguement from mine on wikipedia! — Preceding unsigned comment added by 119.53.109.190 (talk) 03:30, 21 September 2015 (UTC)


I have necessarily to make a response, my words is below,

PAE was first speaking to a IA-32 architecture processor, Pentium Pro exactly. Is the North Bridge part of processors(AMD 10h/10.5h and so many AMD APUs) are really North Bridge chipset? OK, all your referrences are reasonable! But at the nature of that thing (paging under Long Mode), it is not an enhanced version of PAE at all. PAE is short for Physical Address Extension, it extends (maps or translates as you wish) 32-bit linear address (physical address if without further paging) onto 52-bit (reachable) physical address. Obviously and frankly, a real 64-bit processor does not need extending a 64-bit linear address onto a 52-bit physical address, or else this processor (AMD64) is another IA-32 processor! 119.53.109.190 (talk) 05:15, 21 September 2015 (UTC)

Oh... that's what you think? You think that in long mode, 64-bit linear addresses are not translated at all?
Oh. My. God.
In long mode, 64-bit linear (aka "virtual" per the term used by most OSs) addresses are most certainly translated to physical addresses. Long mode does not mean that 64-bit addresses go direct to the RAM; they have to go through address translation (page tables) just like in 32-bit mode with paging enabled. In fact, unlike in 32-bit modes, there is not even a choice about this: long mode cannot even be enabled without paging (address translation) being enabled as well as PAE.
I suggest you review, for example, section 4.5 of the Intel doc Intel® 64 and IA-32 Architectures Software Developer’s Manual, which says exactly:
"With IA-32e paging, linear address are translated using a hierarchy of in-memory paging structures located using the contents of CR3. IA-32e paging translates 48-bit linear addresses to 52-bit physical addresses.1 Although 52 bits corresponds to 4 PBytes, linear addresses are limited to 48 bits; at most 256 TBytes of linear-address space may be accessed at any given time.
(Do not be confused by the references to 48-bit linear (virtual) addresses, this is simply the implemented portion of a 64-bit linear address.)
Also please study carefully Figure 4-8. That's how the page tables look in 64-bit mode (ia-32e) on the Intel64 CPUs. And compare that diagram with the compatibility-mode case, Figure 4-5. Print those diagrams out - or bring them up side by side on your screen(s) - and compare them. Study them. Understand what they are telling you. Do you honestly not see how the former is an "enhanced", or "extended", version of the latter?
For AMD, the doc is AMD64 Architecture Programmer’s Manual Volume 2: System Programming, section 5.3, "Long-Mode Page Translation". Do you understand that "long mode" is what Intel calls "ia-32e" mode? ok. Second paragraph of section 5.3 says
"The PAE-paging data structures support mapping of 64-bit virtual addresses into 52-bit physical addresses."
And I would similarly direct you to a comparison of figure 5-17, "4-Kbyte Page Translation—Long Mode", with 5-9, "4-Kbyte PAE Page Translation—Legacy Mode". Figure 5-17 shows 64-bit linear (virtual) addresses being translated to 52-bit physical addresses, exactly what you claim does not occur. Note that the page table structures include a Page Directory Table, just like under 32-bit PAE, the PD is simply larger. Notice how the long mode version adds another table, the PML4T, but that otherwise the two are very much the same.
On an 32-bit processor you can run without paging enabled, but then there are no page tables, with or without PAE, at all. Long mode never runs that way.
Re your claim that "no 32-bit linear address [is] mapped on the 4-level paging...", that too is incorrect. In compatibility mode "under" long mode (e.g. when running a 32-bit program under a 64-bit OS) the compatibility mode code is of course asserting 32-bit linear addresses, but they are being translated through the long mode-format page tables set up by the OS; it's just that only the first four entries in the PD and the first entry in the PML4 table will ever be used, because those correspond to the address space that is available in compatibility mode.
If you still disagree, if you still think that 64-bit LAs don't go through address translation, then you simply don't understand how addressing works in long mode. So study that stuff until you agree. If you've studied it and you still disagree, study it some more. That is all.
There really isn't any doubt or ambiguity about it, except (apparently) in your poor, mistaken head. That you have labored for so long under this misunderstanding, spent so much time defending conclusions that had no foundation in reality... I honestly feel sorry for you.
I have no idea what "North Bridges" have to do with any of this. Jeh (talk) 05:00, 21 September 2015 (UTC)

Round four

How can a 64-bit address be extended to a 52-bit address? It is a SHRINK! This enhanced version of PAE in Long Mode is merely a paging scheme enhancing from (based on) PAE, but not a version of PAE. Even though in AMD documents it is referred as PAE paging, it might possibly help readers get accustomed to (familiar with) this. It is naturally for a 64-bit processor to page 64-bit virtual address to 64-bit physical address through MMU. My very first AMD64 computer was customised in early 2005, and I get in touch with it for around 10 or more years. You might just get it wrong (misunderstand or miscomprehension of other's purposes)! 119.53.109.190 (talk) 05:32, 21 September 2015 (UTC)


Can we just stop here, and leave those words show here without blanking for a one year? 119.53.109.190 (talk) 06:14, 21 September 2015 (UTC)

First, I see from your 3RR report (there hasn't even been one "revert", btw) that you were upset that I expressed sympathy for your confused condition. Very well, I will refrain from expressing such in the future. I still will, however, take your condition into account, in framing my replies as patiently and as gently as possible.
"How can a 64-bit address be extended to a 52-bit address? It is a SHRINK!"
Nobody ever said that 64-bit addresses were "extended to 52 bits"; that would indeed be a gross misuse of the term "extended". It is the page table structures that are, in long mode, extended. The correct word for your question is "mapped" or "translated".
Now, with the question expressed as
"How can a 64-bit address be mapped to a 52-bit address?"
, I hope you will remember that mapping a bigger address space to a smaller one is an everyday occurrence in virtual memory systems! This is part of the entire purpose of virtual memory!
(Although, I have to point out that it is not always the case that the virtual space is larger than the possible physical address space. On an x86 with PAE, we have 4 GB virtual address space and up to 36-bit physical addresses, i.e. up to 64 GB of RAM. But this situation is more complicated than that because each process usually defines a different virtual address space (via a different page table hierarchy, starting with a different PD and so different CR3 contents), so the total of all processes' v.a.s. could be much larger than 64 GB. You just only have one process's 4 GB virtual mapped in a processor at one time.
Or, think back: Some time ago we all had 32-bit machines - and they all had a 4 GB virtual address space. But until fairly recently most consumer and even "ordinary" business machines had much less than 4 GB RAM. If for example you have had 1 GB RAM, then you had 32 bit virtual addresses being translated to 30-bit physical addresses. Again, that's part of what virtual memory is for. And virtual memory is why we have page tables in the first place!
Are you thinking "but there isn't room?" Remember that once the virtual address space is completely populated (it rarely is even on 32-bit systems and it will likely not be for a long time on 64-bit, but assume it was) there is a page table entry (PTE) for every virtual page number (VPN). Some subset of the PTEs will have their "valid" bit (called in some contexts the "page present" bit) set, indicating that they contain the physical page number (or "page frame number", PFN) that corresponds to the VPN. But the rest will have their "valid" bit clear, and in that case the field of the PTE that would otherwise contain the PFN contains information that the operating system uses to find the contents of the page. In Windows this may be as simple as a "page number" within the pagefile.
I am simplifying this greatly, of course, but that's the gist of it: Your page tables can describe the locations of a larger number of virtual pages than you have physical pages... because you have page table entries for all of the virtual pages... and not all the virtual pages have to be in RAM at one time.
(If you want the complete explanation of how this stuff is done under Windows, how paging works, etc., see the Memory Management chapter of the Windows Internals book I linked earlier. But instead of just reading up on how address translation works you'll have to read nearly all of it. That chapter is about 200 pages, which would be a small-to-medium book all by itself, but it's there.)
"This enhanced version of PAE in Long Mode is merely a paging scheme enhancing from (based on) PAE, but not a version of PAE."
I am afraid your understanding of the word "version" must be faulty. Your denial flies in the face of any reasonable interpretation of the word "version". Anyway, the AMD docs say flatly that it is PAE.
As for "enchanced", it is difficult for me to see how increasing the virtual address size from 32 to 48 bits implemented, and increasing the (theoretical) physical address size from 36 to 52 bits, and adding the NX bit, are not "enhancements". These are certainly not downgrades!
So, that wording stays.
"It is naturally for a 64-bit processor to page 64-bit virtual address to 64-bit physical address through MMU."
Ok, it seems "naturally" [sic] to you. But no matter what your opinion is, that's just not how x64 works, as I have described extensively already, and as documented in the references I've given.
In fact, look through the docs again. (Have you ever actually read them, really studied them? Ever?) Nowhere will you find any reference to 64-bit physical addresses.
To reiterate: In long mode, translation through "enhanced PAE"-style, four-level page tables does happen. There isn't even an option to run in long mode without using page table translation. Good thing, too: Without it we wouldn't have a number of good things, including per-page (as opposed to per-segment, not that we really have segments in long mode) memory protection, re-instantiation of address space for each process (not inherent in the architecture, but it's required by every OS so far), etc., etc.
For another reference, please see Windows Internals 6th Edition, Part 2 by Solomon, Russinovich, and Ionescu, chapter 10, section "Address Translation". It starts on page 251. It says: "Address translation on x64 is similar to x86 PAE, but with a fourth level added." Again ... added, enhanced, extended. QED. Jeh (talk) 10:43, 21 September 2015 (UTC)
This may help you to understand the process better. Even though the 64-bit processor (even with only 48 bits of v.a. implemented) certainly has enough address bits to address all of RAM in any practical configuration, that does not address, for example, the need for multiple processes to re-instantiate the address space. Jeh (talk) 10:04, 1 October 2015 (UTC)

{{Done}} Section started by longtime multiple account abuser, now blocked

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Physical_Address_Extension/Archives/2015/August&oldid=690114169"