Misplaced Pages

This is an old revision of this page, as edited by Jasper Deng (talk | contribs) at 19:05, 13 April 2017 (→"Paging and Virtual Memory": re). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

This article has not yet been rated on Misplaced Pages's content assessment scale. It is of interest to the following WikiProjects:

Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details. Microsoft Windows: Computing Mid‑importance This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Misplaced Pages. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows Mid This article has been rated as Mid-importance on the project's importance scale. This article is supported by WikiProject Computing (assessed as Mid-importance). Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details. Computing Mid‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Misplaced Pages. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Mid This article has been rated as Mid-importance on the project's importance scale.

Archives (Index)

2014/August 2015/February 2015/June 2015/August 2016/July 2017/January 2017/June 2018/September 2020/February 2022/February

This page is archived by ClueBot III.

"offset within page" does not come from the page-table entry

The phrase should surely be . — Preceding unsigned comment added by 83.218.4.174 (talk) 23:56, 12 October 2016 (UTC)

You are of course correct - and nice catch, that's been on the page for a long time. You can of course make the change yourself if you want. Be WP:BOLD ! Jeh (talk) 03:08, 13 October 2016 (UTC)

"Paging and Virtual Memory"

Anyone reading this article should have at least a basic understanding of the concept of virtual memory in my opinion. And perhaps more importantly, the added section still requires such an understanding, because it provides no explanation of what paging and pages are to other readers. Therefore I don't see it as an improvement. It also seems to be copied and pasted from the source (judging from the excessive line breaks) and therefore not allowed.--Jasper Deng (talk) 19:40, 10 April 2017 (UTC)

It also didn't " how PAE works in IA-32" - the only thing it said about PAE is that "IA-32 architecture’s paging mechanism includes extensions that support Physical Address Extensions (PAE) to address physical address space greater than 4 GBytes." That says what PAE does, but doesn't say how it does it. The article already says what it does (in the lede, it says " It defines a page table hierarchy of three levels, with table entries of 64 bits each instead of 32, allowing these CPUs to access a physical address space larger than 4 gigabytes (2 bytes)."), and it later says how it does it (a quick mention in "Design", and a long description in "Page table structures"). Guy Harris (talk) 19:55, 10 April 2017 (UTC)

I'm glad I'm not the only one. I couldn't see where it "explained how PAE works" at all.

Worse: As suspected by Jasper Deng, the disputed material is a direct copy from volume 1, section 3.3.2, of the Intel® 64 and IA-32 Architectures Software Developer’s Manual. There is no doubt or ambiguity about that. The editor even copied the bulleted list from the Intel book as if it was ordinary text, resulting in "inline bullets". I have left a copyvio warning on their talk page.

What is especially odd here is that the same editor, PastieFace (talk · contribs · deleted contribs · logs · filter log · block user · block log), had previously dropped what was basically a CN tag on 3 GB barrier, claiming that a cited reference referred only to the Pentium Pro and that any statements about later processors were CN. Yet this editor is clearly aware of this Intel reference which defines PAE as part of the IA-32 architecture, not specific to any processor.

Both of these articles have been the target of much harassment over the last few years. I note that these recent instances happened shortly after I got a visit from our old friend and long-time sockpuppet Janagewen. Whether there's a connection there or not, I think PastieFace's future attempts can be ignored on WP:CIR grounds, and should be checked for WP:COPYVIO as well. Jeh (talk) 07:59, 11 April 2017 (UTC)

@PastieFace: If you bothered to look at the section on "Operating system support" you'll see that it's not a Windows-specific thing. And virtual memory has everything to do with it: each virtual address space remains 32-bit even if the physical memory is bigger, as your edit even mentions. If you do not have a good understanding of this concept, I suggest you avoid this topic.--Jasper Deng (talk) 20:28, 12 April 2017 (UTC)

Furthermore, if you don't have paging virtual memory enabled, PAE doesn't even exist - PAE involves a modified form of the page table, with larger page table entries capable of providing more bits of physical address, expanding the physical addresses generated for virtual addresses from 32 bits to 36 bits. Guy Harris (talk) 20:45, 12 April 2017 (UTC)

And wider on x64 processors while in long mode. Jeh (talk) 21:11, 12 April 2017 (UTC)

Further²more: PF claims PAE is Intel-only. That is wrong. PAE has been supported by AMD CPUs since the Athlon (K7) and continues in the K8, even when the latter is in legacy mode (ie running as an x86 CPU). It is true that AMD's support for PAE came several years later than Intel's: Intel had it in the Pentium Pro, late 1995, while AMD didn't have it until the Athlon, mid 1999.

So, yes, for a time, Intel supported PAE while AMD did not. But that time ended over 15 years ago!

I wish I could quote a K7-era AMD Architecture manual, but I can't find one. The oldest I have is the original hardcopy set for the AMD64 architecture, which does show that PAE is available on the K8 in legacy mode, but that isn't definitive for the K7. The online sources I've found are more recent still, but one would hope that they would at least disabuse PF of the notion that AMD doesn't support PAE at all on any platform. (See AMD64 Architecture Programmer’s Manual, Volume 2: System Programming, section 5.2.3 for legacy mode. For long mode, see 5.3: "Because PAE is always enabled in long mode ..."

On the bright side, PastiF's mistaken ideas have suggested to me a new diagram that may eliminate misconceptions like " once a process hit the 4GB limit, IA-32 CPU would start paging in and out of RAM using internal registers., that's what PAE is." (from PastieFace's edit to my talk page) (No, the CPU does not do that, and that isn't what PAE is.) Jeh (talk) 21:11, 12 April 2017 (UTC)

I'm not sure AMD had an overall ISA manual before AMD64, as the ISA they implemented was "IA-32, possibly without the latest and shiniest Intel extensions, but with some of our own extensions such as 3DNow!", and they may just have expected developers to rely on Intel's ISA documentation plus their supplemental documentation on extensions such as 3DNow!. I tried digging through the Wayback Machine's early-2000 archive of amd.com, but at least one PDF document they had didn't fully download and, if I tried downloading it from the command line, neither Preview nor the latest version of Acrobat Reader for Mac can open it (they both report it as damaged). Guy Harris (talk) 01:48, 13 April 2017 (UTC)

The infamous table at x86 says the K7 has PAE, but the claim is not referenced. Jeh (talk) 02:53, 13 April 2017 (UTC)

Correction... it's referenced now. *grin* Jeh (talk) 10:14, 13 April 2017 (UTC)

Thanks! I've copied that reference to this page as well. Guy Harris (talk) 10:27, 13 April 2017 (UTC)

You guys can try and gang bang me and babbletalk all you like, it won't phase me. Actually I expected this. Some of the comments here read like the MSDN library articles on Windows Memory limitations which neither my peers or myself have able to decode as yet... The tech writers did their jobs well. Obfuscation is 2nd nature to developers. Easy to ignore it however since some of us rely on empirical evidence for answers.

@Jasper - 1st comment I said it is specific to Windows and Intel. 1: There is PAE designed by and implemented by Intel on architecture which allows processes to be paged in and out of the working set. Like pagefile only faster ofc as it's paging from RAM not the HDD. It's all just storage anyway. Working set still same 4GB however so the extra RAM was mainly used for file caching on servers.

2: Microsoft's name for a "32bit OS" which can magically handle over 4GB total is PAE. This concept is smoke and mirrors anyway: An OS is essentially many programs running at once inside a user friendly GUI. Programs are made up of process, then threads which ofc run on a CPU cores. So how does an OS determine a memory limit for the hardware which hosts it. Because big daddy kernel (basically a gateway) limits processes from asking for more space. ... like Oliver Twist CPU by way of. The number of processes which can run on the hardware in truth is up to the hardware. It's the kernel which (artificially to an extent) prevents any more addresses being handed to the CPU for staorage.. S

So with Windows PAE a more accurate depiction would be a restriction is lifted, nothing is extended or added.

PAE for processors isn't needed by AMD64, due to a couple of fundamental architecture difference between AMD64 and IA32/64. One being AMD64 MCT don't need linear addresses when translating between virtual and physical addresses.

From CPU to RAM 64 address lines were available, clearly more than what a Windows 32bit OS can handle. There are more address lines also leading from the CPU to chipset NB. These are the internal registers, these lines are how pages get swapped from the pagefile to RAM,among other things.

IA32 needs the internal registers when running 64bit OS because IA32 (not IA32e) can only handle 64bit processes if the pagefile is enabled. 

Without a PF total address space period for IA32 is 4GB.

Which brings us to the :"Driver Incompatibly" issue MS would have us consumers believe.

So IA-32 dependant on model get 32physical lines going to the Northbridge, 32 going to Southbridge Intel-64 had 32/64. Xeon had 64/64. correct me if I'm wrong as I'm working from memory.

And please don't insult my intelligence by actually suggesting I read a Misplaced Pages article on VM or anything recommend

In AMD's case Windows has to extend its own addresses beyond 4GB in order to use all address space available to the CPU The onus is on an OS to be able to use all the address space available to the CPU not the other way around. Hardware doesn't run on an Operating System the Operating System runs on the hardware. Tell me again how PAE works for AMD64?

Anyway Intel was the opposite, and tbh the "Physical" when it comes to Physical Address Space is a misgnoner. Windows doesn't control the AMD Northbridge, The CPU does, and it can address as much memory as it was designed for. The OS can only limit it's own addressing.

And re: my talk, how bout u let Jeh answer for himself.

PAE isn't actually relevant after XP anyway since MS use licensing checks.

Which is another topic in in itself. How can PAE "add" something that was always there? XPSP1 on AMD64 8GB was accessable no problem, XPSP2 comes along which prevented the OS from using addresses over 4GB. Not the CPU's fault.

Sounds more like Physical Address Reduction, not Extension. Somebody please remind me.....the difference between XP and Server 2003 is.....what? The cost?

@Guy Harris, some of what you said doesn't make sense.

Furthermore, if you don't have paging virtual memory enabled, PAE doesn't even exist - PAE involves a modified form of the page table, with larger page table entries capable of providing more bits of physical address, expanding the physical addresses generated for virtual addresses from 32 bits to 36 bits.

No kidding that's why it doesn't have any effect on AMD64. Why not just say "PAE enables paging on the CPU? Or something to that effect..

And "paging virtual memory"? What is "paging virtual memory"? I know of pagefile, page table, pages, virtual memory, even tables. But "paging virtual memory" is new one to me. Any links to technical documentation explaining the concept of "paging virtual memory" - much appreciated. I love learning new tech.

"PAE involves a modified form of the page table?" My 7 year old niece could quote that line back to me, right after reading wikipedia. How about describing the page table modification in detail? Let me: PAE doesn't add a page table it adds a page table directory pointer which points to the page table. Simple. Any other obvious info I need to be made aware of as you assert your superior knowledge?

As above 36bit addressing was needed because Intel hardware generally had 32bits external for RAM access, less 4bits was for the page table directory pointer. Possibly why x87 compilers limited 32bit processes to ~3.6GB or 3.7GB. AMD don't need or use or know about PAE because all their page tables are stored in RAM which is entirely and directly accessible by the CPU without paging.

Attempting to fluster users/editors with jibberish and nonsensical terms.... is pretty unethical, who wins nobody?

Lastly, Microsoft are software developers, not ASIC manufactures. MS work very closely with Intel. An expertise in one does not mean expertise in the other. Just some food for thought.

@Jeh, thanks, this is a great example of why I wasn't interested in going to talk with you. Had a reasonable discussion been on the cards yes by all means, I would look forward to it. Tbh I'm not even sure if some of the more nonsensical comments posted here were intended or not.. But I assume good faith.

And no, I didn't use quotes, possibly there may be duplicate comments too..I didn't check.PastieFace (talk) 10:55, 13 April 2017 (UTC)

@PastieFace: And your comment here still indicates that you don't understand this topic. An operating system is not just "essentially many programs running at once inside a user friendly GUI." An operating system has to schedule those programs while providing isolation. And most programs and server operating systems don't even expose a GUI to the user at all. Your comment that "There is PAE designed by and implemented by Intel on architecture which allows processes to be paged in and out of the working set." is also incorrect, because physical pages are by definition in RAM (where else? The CPU cache has nothing to do with this concept). Also "Because big daddy kernel (basically a gateway) limits processes from asking for more space." is incorrect because the whole story of memory management is invisible to user processes. If a process only speaks 32-bit addresses it literally can't ask for more than 4 GB of memory, period. That's not a restriction imposed by the OS, unless the OS decides to be stricter for any reason. "PAE isn't actually relevant after XP anyway since MS use licensing checks. " - again, incorrect: PAE is relevant to 32-bit versions of Windows Server 2008 (and most other 32-bit versions of Windows, for that matter), which postdates Windows XP. "Which brings us to the 'Driver Incompatibly' issue MS would have us consumers believe." - let me ask you, do kernel mode drivers have the luxury of virtual memory?

"And please don't insult my intelligence by actually suggesting I read a Misplaced Pages article on VM or anything recommend" - if you tell us blatantly incorrect things such as the notion that PAE is only a Windows on Intel thing, what else am I supposed to infer? And "As above 36bit addressing was needed because Intel hardware generally had 32bits external for RAM access, less 4bits was for the page table directory pointer." is incorrect. That's not how a 3-level page table works. "AMD don't need or use or know about PAE because all their page tables are stored in RAM which is entirely and directly accessible by the CPU without paging." Uhm no - at least in recent versions of AMD processors, there are still hardware page tables, and even nested page tables for virtualization (Extended Page Table).

None of this is directly relevant to the edit in question, anyways. The fact is, your addition said nothing new whatsoever on the subject of PAE and was a direct copy/paste from the manual, and consensus has therefore been against it, so it will stay out of the article.--Jasper Deng (talk) 15:31, 13 April 2017 (UTC)

@PastieFace:, well, after reading your words I found you confuse too much a lot. PAE is not some a new thing, and AMD Athlon (K7) supports PAE is not some a special news too. In 2001, when I managed my computer with Red Hat Linux 6.3, I was involved to recompiled the kernel with PAE enabled for Athlon 800MHz processor, Socket A. In order to support memory larger than 4GB, I also updated Windows NT 4.0 from SP0 to SP6a in late 2000, to support and enable PAE feature. The main article is a little bit misleading, but everything is just alright. But I have some words to say around Windows XP, IA-32, AMD64 and Itanium.

In late 2001, I obtained an copy of Windows XP Professional RTM in August, 2001, the same year later, I also obtained another copy of Windows XP 64-bit Edition. At that moment, from one could see clearly that Microsoft initially abandoned the support of AMD64 architecture, put major focus on the 64-bit Itanium platform. So they want 32-bit Windows XP Professional to do even more than later. That is the reason why Windows XP SP1 could support memory more than 4GB, when SP2 released such a thing vanished. After Service Pack 1 released, Microsoft faced with a lot of headache problems around Windows XP 64-bit Edition. They had to release a second version of it, in the codebase of Windows Server 2003, and that is the Windows XP 64-bit Edition, Version 2003. Even after this version released, Microsoft also found some tough problems on development and marketing. So they delight the fire of supporting the abandoned AMD64 architecture. They tried their best to make complex simple, to make idealised practical. That is the very reason that they eventually release a third version of Windows XP 64-bit Edition, not for Itanium, but for AMD64.

AMD64 is a standalone architecture, but AMD feared that it could fail in the market, so they enabled their processors to support legacy 32-bit software, in the form of disguising those processors initialised as AMD Athlon before entering into the Long Mode. So if one does not use 64-bit OS, this processor would all the time work like yesterday's AMD Athlon. On the other hand, Microsoft realised the investment on the Itanium architecture is a failure long before 2012, when Windows Server 2012 no longer support this architecture. So they just use AMD64 architecture as a make-up for those investment on Itanium. So Microsoft treat AMD64 architecture as merely the world under Long Mode. Smelling this taste, Intel enabled all their future processors to support this architecture. They do not want to compromise towards AMD, so they intentionally refer this new architecture as merely an 64-bit extension, but in fact, the true story never told like that. In order to satisfy both Intel and AMD, Microsoft eventually name their new product as x64, not merely extension, and not merely a completely new architecture. But just something which x64 could say exactly, but for the background, they stick to the word, AMD64. And they believe AMD64 is an architecture, a standalone architecture, rather than merely an 64-bit extension. Later Intel and Apple make up another story, forcing the end users believing that this faked extension. And that story ends when OS X 10.8 released.

If AMD64 is a standalone architecture, how can someone still call it an enhanced version of PAE, only if he/she could obtain profit from it, and stick to it.

--- Aaron Janagewen

@Guy Harris; I'm retracting my reply to your comment "paging virtual memory". After thinking it over I agree with you, technically you're right since PAE essentally just allows paging. I always looked at it as paging from where didn't matter ver. The terminology tripped me up as to me paging is paging no matter where from or to. I realised also your comment nullifies any argument over whether IA32 can access over 4GB of RAM. Also it illustrates how the "P" in PAE is quite misleading. :)PastieFace (talk) 17:48, 13 April 2017 (UTC)

@Aaron, yes after rereading I realised a couple of minor comments made were not 100% accurate. One was obviously stating the pagefile allows 64bit processes to run. :P Also, I realise PAE is not new but in the context of the article it is ambiguous to imply x86/64 processors in general make use of PAE. Just as to state 32bit (physical bits) architecture in general can support as much RAM as 40bit or more. This POV comes across to me as very biased toward Intel and snubbing AMD. I suggest the above mentioned topics be broken down by vendor and micro-architecture to maintain neutrality. Thoughts? PastieFace (talk) 18:16, 13 April 2017 (UTC)

@PastieFace: Please remember to indent your comments by prefixing each new line break with the appropriate number of colons in the markup.

And also, PAE itself is not the enabler of paging, which predates PAE by quite a long time. Rather, it allows a greater total size of the set of physical pages to take advantage of more memory.

I opened this conversation to discuss the edit you made. Do you still stand by that edit?--Jasper Deng (talk) 18:29, 13 April 2017 (UTC)

@PastieFace: Yes, PAE is just a change to the way paging works at the hardware level. It extends the size of page table entries to 64 bits, allowing them to have more bits of physical address. Without it, an IA-32 processor, whether from Intel (80386 onwards) or AMD (Am386 onwards) can generate a 32-bit physical address, so it can only handle 4GB of physical memory; with it, an IA-32 processor, whether from Intel (Pentium Pro onwards) or AMD (Athlon onwards), can generate a 36-bit physical address, so it can handle up to 64GB of physical memory (if the chipset and motherboard can). Both without and with PAE, the logical addresses that are mapped to physical addresses are 32-bits long. IA-32 processors with PAE cannot support more than 2^36 bits of physical address; it can't support 2^40 bits of physical address, whether the processor is from Intel or AMD.

As for x86-64, whether from AMD (Opteron onwards - AMD originally called it x86-64, but changed it to AMD64) or Intel (64-bit versions of the Pentium 4 onwards - Intel calls it EM64T, IA-32e, or Intel64, depending on the phase of the moon), it uses 64-bit page table entries, just as IA-32 with PAE does, but the page map has more levels, so it can map a 48-bit address to a physical address. The physical address size varies from processor to processor, but it's at least 40 bits. Those aren't IA-32 processors, those are x86-64 processors, so they're not limited to 32 bits in linear addresses and are not limited to 36 bits in physical addresses.

So there's not much "AMD vs. Intel" here; both Intel and AMD implement paging since the 80386/Am386, both Intel and AMD implement PAE since the Pentium Pro/Athlon, and both AMD and Intel implement x86-64 since the Opteron/later Pentium 4.

And the only way the microarchitecture makes a difference is the number of physical addresses that a 64-bit microarchitecture, implementing x86-64, provides. All 32-bit microarchitectures that provided PAE provided 36 bits of physical address.

So there's no neutrality issue, and there's no need to break anything down by vendor or microarchitecture. The only distinction to be drawn is between IA-32 with PAE and x86-64, and this page primarily covers IA-32 with PAE, as it should. PAE isn't an option in x86-64 - you have to turn PAE on to do paging in long mode - but the page map is different in that mode (one more level, to handle the longer virtual addresses), and that is described in x86-64. Guy Harris (talk) 18:52, 13 April 2017 (UTC)

@Jasper: :"And also, PAE itself is not the enabler of paging, which predates PAE by quite a long time"

In reply to the first half of your sentence PAE is the method by which processors which use PAE page out. The 2nd half is not even relevant to anything I said because I never discussed where PAE originated from nor care for that matter. However if you're going to tutor me on PSE don't bother. It's not even important.

Re: edits which part in particular are you referring to? Regardless if I stand by it you will know because it will be reverted, no need to worry. Besides the talk page is here for these discussions.

Tbh I haven't even gone through the revisions since the other day as been too busy. I hardly have time to reply now...PastieFace (talk) 18:49, 13 April 2017 (UTC)

No, PAE is the mechanism by which processors that use PAE map 32-bit linear addresses to 36-bit physical addresses, rather than just to 32-bit physical addresses, as they have to do without PAE. Paging in and out can be done the same both ways, even if Microsoft chose to handle physical memory beyond 4GB differently. Guy Harris (talk) 18:58, 13 April 2017 (UTC)

@PastieFace: To say that PAE "enables" paging is to imply that paging is not possible without PAE, which is obviously not true. I assume you understand what Guy Harris means by paging virtual memory because paging is not the only way to do virtual memory (although it is considered the best we have right now).

As for the edit in question I'm referring to this. Since as you know by now, reverting excessively (edit warring) is no way to indicate objections to an edit, I felt it necessary to ask you here.--Jasper Deng (talk) 19:05, 13 April 2017 (UTC)

• All unassessed articles
• C-Class Microsoft Windows articles
• Mid-importance Microsoft Windows articles
• C-Class Computing articles
• Mid-importance Computing articles
• All Computing articles
• WikiProject Microsoft Windows articles