Jump to content

Talk:Physical Address Extension

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 119.53.109.190 (talk) at 03:00, 21 September 2015 (→‎Regarding "an enhanced version of PAE" vs ...). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.



Archives (Index)

This page is archived by ClueBot III.

PAE is A Processor Feature

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)[reply]

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)[reply]

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)[reply]
I haven't gotten around to replying to your complaint about "enhanced paging schema". Jeh (talk) 04:28, 19 September 2015 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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)[reply]

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)[reply]


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!

Meaningless Replies or Damaging Threats towards Wikipedia

From Jeh,

Reported as likely sock of serial sockmaster Janagewen. https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/Janagewen Jeh (talk) 00:00, 19 September 2015 (UTC)[reply]

this list might be enlarged in uncertain future time. CopperQA (talk) 00:30, 19 September 2015 (UTC)[reply]

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