Talk:Physical Address Extension/Archives/2014/August

Vista data

Doesn't 64 bit Vista suppport more then 4 Gb? I think the table is misleading. I don't know the actual values though to edit the page 199.46.164.199 (talk) 19:54, 25 August 2009 (UTC)

Win32 supports 64GB PAE?

Clearly there is incongruence in this article! The first paragraph states that PAE enables address extensions past 4GB, YET, almost ALL of the Windows 32 bit OS's mentioned later do NOT support address spaces greater than 4GB....what gives?! —Preceding unsigned comment added by 129.82.238.170 (talk) 15:58, 22 July 2009 (UTC)

PAE enables physical addresses beyond 4GB. 32-bit Windows OSs are limited to 4GB of virtual address space. Jeh (talk) 05:07, 8 January 2010 (UTC)

The MikroS-PR marketed in-genius cover up and MS pr-dept. have to feed 'MS do not lience PAE' what mean == 'PAE does not work on 32 MikS.

It works fine on 32-bit Server editions. Jeh (talk) 05:19, 25 October 2010 (UTC)

The table on PAE support in Windows conflicts with data given in in this article: http://msdn.microsoft.com/en-us/library/aa366796(VS.85).aspx

"Physical Address Extension (PAE) enables x86 processors to access up to 64 GB of physical memory and x64 processors to access up to 1024 GB of physical memory." —Preceding unsigned comment added by 87.153.61.35 (talk) 11:16, 27 January 2009 (UTC)

Also, the table legend is not clear : what is the definition of the columns. Is it maximum virtual space, maximum physical space ? —Preceding unsigned comment added by 79.85.191.199 (talk) 10:58, 5 August 2010 (UTC)

All Windows 32 bit OS kernels support greater than 4GB (up to 64GB) through PAE however it is disabled in the consumer versions of the OS. See Win2003 and Win2008 32-bit versions for reference. Windows 2008 R1 and R2 have *identical* kernels to Vista and Win7 respectively. See for 32-bit memory limitations.125.255.46.67 (talk) 00:23, 1 December 2010 (UTC)

First Linux version to support PAE

In an IRC talk Rik van Riel stated:

< riel> I'd have to check the RHEL 2.1 kernel
< riel> I know it has PAE support
[...]
< riel> ok, PAE was already in 2.4.9
< riel> which predates the forking of the 2.5 development tree
< riel> PAE was probably introduced during 2.3

so probably the quoted article is wrong. Could someone check when PAE support was first introduced to the Linux kernel and correct the article? —Preceding unsigned comment added by 62.152.87.202 (talk) 14:41, 28 October 2008 (UTC)

Fixed, the git-historic tree makes it very easy to check things like this (git://git.kernel.org/pub/scm/linux/kernel/git/davej/history.git).

--79.136.121.226 (talk) 12:50, 11 October 2009 (UTC)

Plural or singular?

Shouldn't this article be at Physical Address Extensions? Documents I've seen from both AMD and Intel always seem to refer to it in plural. JulesH 17:39, 8 October 2006 (UTC)

Microsoft seems to use the singular: http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx 198.20.50.34 14:50, 20 August 2007 (UTC)

Intel seems to use the singular: http://www.intel.com/design/processor/manuals/253668.pdf Guy Harris 01:29, 21 August 2007 (UTC)

Page Size Extension

Shouldn't there be a section contrasting and comparing Page Size Extension to Physical Address Extension? Dsf7183 10:22, 15 November 2007 (PST)

Probably. Be bold! Jeh (talk) 00:07, 10 January 2008 (UTC)

Windows: paragraph re. Address Windowsing Extensions removed

I just removed this graf:

Access to physical memory greater than 4 GiB by 32-bit applications is by means of Address Windowing Extensions (AWE), which works something like Expanded memory (EMS) and Extended Memory (XMS) on 16-bit systems.

Reason - AWE really is unrelated to the PAE mechanism. You can use AWE APIs, and they will work (if you don't ask for much RAM), on a system not running in PAE mode. Hence it is not limited to accessing "physical memory greater than 4 GiB." It is just that only on systems with a LOT of physical memory, and will an app have much reason to use AWE. Jeh (talk) 00:05, 10 January 2008 (UTC)

Workaround for the XP SP2 32-bit physical address limit? No, sorry.

The Windows section previously contained

If PAE is enabled in the normal way, this compatiblity hack is disabled. See [1].

The link had been there for some time but the sentence preceding it ("If PAE is enabled...") was new. Anyway, I'm afraid that both are incorrect. As someone at the end of that very blog page stated, you can try all the ways and combinations of ways to enable PAE you like; you still can't access RAM above the 4 GiB address boundary. And because of conflicts with PCI device space below the 4 GiB point, you can't access all of 4 GiB of RAM on these systems either. Jeh (talk) 03:17, 10 January 2008 (UTC)

From [2]:

"If you add the /PAE switch, you get the normal PAE behavior, and all bets are off. Of course, this is exactly what you want in the server space; after all, you got that extra RAM for a reason, right? Also note that the properties aren’t transitive. While both /PAE and /NoExecute use the same kernel file (ntkrnlpa.exe or ntkrpamp.exe) and address translation mechanism, you need both switches in place to enable both features." - Yuhong (talk) 21:15, 12 January 2008 (UTC)

Sorry but IT DOES NOT WORK AS THAT PAGE CLAIMS. I've tried it myself -- it doesn't work. Jeh (talk) 21:56, 12 January 2008 (UTC)

BTW, not all chipsets and BIOSes support more than 32-bit physical address space. If it doesn't work on 64-bit OSes that must be the cause. —Preceding unsigned comment added by 207.34.170.129 (talk) 21:59, 12 January 2008 (UTC)

Sorry, but no. I have here a machine with 8 GiB RAM installed, and all is available on a 64 bit OS. This hack does not work to allow Vista x86 or XP SP2 x86 to see more than about 3.2 GiB. Jeh (talk) 22:03, 12 January 2008 (UTC)

How about on Server 2003 SP1 Enterprise x86? - Yuhong (talk) 22:05, 12 January 2008 (UTC)

Server was never subject to the "cripple"! Only the client OSs. If /pae is necessary to see RAM addrs > 4 GB on Server 2003, even if /noexecute=(not-disable) is already there, that is an interesting point, but it deosn't help the folks running client OSs who can't see all their RAM. Jeh (talk) 22:12, 12 January 2008 (UTC)

Re your most recent change to the page... this I have not tested (yet), but I don't believe the /PAE switch is needed on Server as long as /noexecute is there with anything other than /noexecute=disable . Do you have a reference other than your own blog page? Jeh (talk) 22:20, 12 January 2008 (UTC)

I don't think that is true. Please test. - Yuhong (talk) 19:22, 13 January 2008 (UTC)

I will. It won't be today, but likely within the week! Jeh (talk) 22:30, 13 January 2008 (UTC)

I've tested this myself with Windows 7 - on 64-bit all of my 6GB are available, and with a kernel hack on 32-bit I was not only able to "see" the full 6GB, but actually use it by calling multiple instances of a RAM allocation program (allocates 2GB per instance, I ran three and all three took 2GB). I can't speak for XP, however. -Anonymous

What "kernel hack", exactly? Jeh (talk) 16:53, 6 September 2010 (UTC)

Not windows specific...

Why on earth is this "WikiProject Microsoft Windows", PAE is used by Linux as well and several other operating systems, it is hardware feature not something windows specific. --83.181.53.188 (talk) 22:38, 3 March 2008 (UTC)

It can be part of other projects too. Nothing says an article has to be part of just one project! Jeh (talk) 04:23, 4 March 2008 (UTC)

Illustrations for PAE

I made some drawings illustrating how PAE (and non-PAE paging on x86) works. Perhaps you find them useful for the article?

• 
• 
• 
• 

--81.27.124.124 (talk) 20:32, 26 March 2008 (UTC) (RokerHRO)

Good work. Could you fix this one, it says 4KB instead of 2MB? --Kubanczyk (talk) 09:31, 27 March 2008 (UTC)

I would suggest that low addresses or offsets or index values should go at the top of the page and high at the bottom. This is the way e.g. debuggers display memory, and is also the way e.g. structures are defined in languages such as C: Offsets start at 0 at the top of the page, or output, or the first line of the struct definition, and increase in value as you go "down" te page, or etc. Jeh (talk) 15:14, 27 March 2008 (UTC)

Maybe. I got the idea for these images from the original Intel documentation. And I think "low" addresses should be shown at the bottom, growing upwards. I think it is a kind of "vertical endianess". ;-) --RokerHRO (talk) 06:56, 21 December 2010 (UTC)

the footnotes are ambiguous

"1 GB = 1024 MB" is an ambiguous statement. If you click on the link you find that MB has three different definitions.

Not ambiguous and you made the edit on May 5 to not use IEC. The refs make the disambiguation unambiguous because they include GB MB and KB. DavidPaulHamilton (talk) 16:02, 8 May 2008 (UTC)

In the interests of trying to stop the numerous reverts I added extra disambiguation for 1 GB = 1024 MB to say "1 GB = 1024 MB ; 1 MB = 1024 KB ; 1 KB = 1024 B" and also added similar for MB. KB and PB don't need extra disambiguation as it is already precisely clear what they mean from the footnote. This article does not currently mention any file sizes using these prefixes so it is unambiguous and precise to not include any other explanatory text in the footnotes regarding binary or decimal use. I think it would be too bloated to include "This article uses prefixes in a binary sense" in each footnote since the exact quantities are already disambiguated and the article doesn't change between binary and decimal use. However, if you want to add that text Thunderbird2 then you can. Fnagaton 16:48, 8 May 2008 (UTC)

Why is this article not using IEC? —Preceding unsigned comment added by 74.73.6.35 (talk) 03:30, 19 July 2008 (UTC)

From WP:MOSNUM "The IEC prefixes are not to be used on Wikipedia...".Fnagaton 08:42, 19 July 2008 (UTC)

Where is the consensus to support that statement? Thunderbird2 (talk) 08:50, 19 July 2008 (UTC)

As shown in the talk section you linked there is no consensus for your point of view. Also the consensus for the guideline text is Wikipedia talk:Manual of Style (dates and numbers)/Archive/Complete rewrite of Units of Measurements (June 2008)Fnagaton 08:53, 19 July 2008 (UTC)

PAE not a magic bullet

I remember that I read some years ago a lengthy articel on the linux kernel mailing list and in a german magazin (c't? iX? OpenUnix?) that PAE under Linux comes with the same caveats as on most systems: Many drivers don't support PAE fully so often you can not use PAE even though your kernel and some drivers might work with PAE. The cheapest workaround is to limit PAE within the physical address space so your drivers don't skip on it. In fact PAE isn't quite as easy to handle for DMA, SMP, block allocation and so on, you have to do a lot more locking, synching and so on and even if you DO use PAE without bugs you WILL get a measurable slow down of overall performance of some percentage.

Short Form: PAE is not a magic bullet. It comes with draw backs and makes mostly sense in applications which really need LOTS of memory but only moderate CPU power. Databases come into my mind.

No sources as I really tried hard to recover the articles without success. —Preceding unsigned comment added by 88.217.9.104 (talk) 01:03, 29 November 2008 (UTC)

I think device driver limitations have been overcome with newer releases of Linux and newer x86 products. The PCI section of the DMA page talks about support for bounce buffers and DAC.

98.204.35.128 (talk) 12:14, 27 May 2011 (UTC)

PAE and EMS

PAE sounds awfully like EMS (Expanded Memory Specification), where extra memory beyond 1Mb on the 8086/88 processors could be mapped into a 64k page below the 1Mb. Perhaps a comparison between the two would help clarify? 70.58.156.84 (talk) 05:16, 11 February 2009 (UTC)

No, it isn't much like EMS at all. EMS doesn't involve page table-based address translation, for one thing. For another, applications have to be written to directly use EMS, whereas PAE is completely transparent to applications. PAE is really nothing more than an alternate page table format that supports more bits of physical address. Jeh (talk) 05:34, 11 February 2009 (UTC)

No PAE support for 533MHz FSB Pentium M

--Wdmsw (talk) 22:03, 17 June 2009 (UTC)

The Pentium-M (with a 533MHz FSB) does not support PAE, as the highest order address bit is A31 (indicating 32-bit physical addressing). See link below for datasheet:

datasheet

The manner in which the exception is stated in the article implies that the 533MHz FSB Pentium M would support PAE:

"(including all later Pentium-series processors except the 400 MHz bus versions of the Pentium M)"

Suggest striking or modifying content in parenthesis for accuracy.

Limit in practice is even lower than 4GB on 32-bit Windows

This article makes it clear, in the Windows section, that Windows is limited to a theoretical maximum of 4GB, even though it is capable in principle of addressing more. It does not make it clear that the practical maximum is even lower than that due to memory mapping for device drivers, typically more like 3.5GB. What's more even the 4GB limit isn't mentioned in the lead. My worry is that people will come to this page and, as I almost did, just think "ah this means that I can buy 4GB or more for my 32-bit Windows PC and it will all work fine".

I know we shouldn't write this page in a Windows-centric way, but giving Windows a single sentence in the lead section is reasonable given its immense market share. I think something like "Even though recent 32-bit client editions of Microsoft Windows have this feature enabled, they are still limited to 4GB, or in practice usually closer to 3.5GB, for licensing and compatibility reasons". The main reason I haven't gone ahead and done it myself is I think one or two good sources for the "about 3.5GB" are needed. 86.156.90.87 (talk) 13:46, 18 January 2010 (UTC)

The "about 3.5GB" isn't really a windows centric issue, it's a reflection of the fact that ram isn't the only thing that uses address space. This means on a machine with 4GB or more of ram some ram is pushed beyond the 4GB address space barrier. Plugwash (talk) 01:10, 12 May 2010 (UTC)

It is. Ony my 4-GiB-PC /proc/iomem (Linux 2.6 on x86_64) shows (I stripped out the 2nd and 3rd level entries):

   00000000-0000ffff : reserved
   00010000-0009fbff : System RAM
   0009fc00-0009ffff : reserved
   000c0000-000cffff : pnp 00:0c
   000e4000-000fffff : reserved
   00100000-cff8ffff : System RAM
   cff90000-cff9dfff : ACPI Tables
   cff9e000-cffdffff : ACPI Non-volatile Storage
   cffe0000-cffedfff : reserved
   cffee000-cffeffff : RAM buffer
   cfff0000-cfffffff : reserved
   d0000000-dfffffff : PCI Bus 0000:01
   e0000000-efffffff : PCI MMCONFIG 0 [00-ff]
   fdf00000-fdffffff : PCI Bus 0000:02
   fe7f4000-fe7f7fff : 0000:00:14.2
   fe7f9000-fe7f9fff : 0000:00:14.5
   fe7fa800-fe7fa8ff : 0000:00:13.2
   fe7fb000-fe7fbfff : 0000:00:13.1
   fe7fc000-fe7fcfff : 0000:00:13.0
   fe7fd000-fe7fdfff : 0000:00:12.1
   fe7fe000-fe7fefff : 0000:00:12.0
   fe7ff000-fe7ff0ff : 0000:00:12.2
   fe7ff800-fe7ffbff : 0000:00:11.0
   fe800000-fe9fffff : PCI Bus 0000:01
   fea00000-feafffff : PCI Bus 0000:02
   feb00000-febfffff : PCI Bus 0000:03
   fec00000-fec00fff : IOAPIC 0
   fec10000-fec1001f : pnp 00:09
   fed00000-fed003ff : HPET 2
   fee00000-fee00fff : Local APIC
   ffb80000-ffbfffff : pnp 00:09
   fff00000-ffffffff : reserved
   100000000-11fffffff : System RAM  <--- REMAPPED RAM! :-D

That reminds me on the tricks done by old 80286 NEAT chipsets that supported 1 MiB RAM but remaps the uppermost 384 KiB beyond the 1-MiB barrier because the PC architecture expects no main memory in the 0xA0000…0xFFFFF address range. --RokerHRO (talk) 23:41, 28 March 2011 (UTC)

Correct - the "3.5GB or so" is Windows-centric. Linux allows itself to use RAM that was remapped above the 4 GB boundary, whereas Windows client versions don't, so remapped RAM might as well not be there as far as Windows is concerned. See the 3GB barrier article. Jeh (talk) 09:39, 29 March 2011 (UTC)

Windows Versions Comparison: Table Restructured

I am not sure in which extent the 64-bit Windows editions use PAE (except for NX support?), but even just for comparing the 64-bit to the 32-bit editions, and also to see the artificial restrictions in most Windows editions, the table makes sense as it is. --Mopskatze (talk) 13:14, 7 April 2010 (UTC)

128GB RAM - is that correct??

In the article, I read in the table that Windows Server 2003 Datacenter (SP2) 32-bit supports up to 128GB RAM. Is that correct? If so, how can it support 128GB of memory when PAE supports a maximum of 64GB of memory?????

Please explain because it's totally confusing!???! TurboForce (talk) 19:07, 4 August 2010 (UTC)

The 64GB limit is for the original implementation of PAE, which implemented 36 bit physical addresses. Later CPUs, particularly those that implement either Intel or AMD's version of x86-64, support wider physical addresses, hence more RAM, in PAE mode, even when running a 32-bit OS. Jeh (talk) 22:54, 4 August 2010 (UTC)

Thank you Jeh. Please could we add this info to the article with the technical information you're describing. At this moment in time, reading the Wikipedia page about Physical Address Extension gives readers the impression that PAE support on later CPUs still only allows 64GB of RAM. Cheers. :) TurboForce (talk) 11:29, 5 August 2010 (UTC)

User Jeh is right. I've just read in the Intel IA32 Software Developers Guid, Book 3a (System Programming Guide) on chaper 4.4:

PAE paging translates 32-bit linear addresses to 52-bit physical addresses.¹ Although 52 bits corresponds to 4 PBytes, linear addresses are limited to 32 bits; at most 4 GBytes of linear-address space may be accessed at any given time. [...]

---

Footnote 1: If MAXPHYADDR < 52, bits in the range 51:MAXPHYADDR will be 0 in any physical address used by PAE paging. (The corresponding bits are reserved in the paging-structure entries.) See Section 4.1.4 for how to determine MAXPHYADDR.

We should fix the article about t hat fact. --RokerHRO (talk) 11:29, 27 September 2010 (UTC)

I can still see claims that certain 32-bit versions of Windows can support 128GB of RAM - but I can't find any reference to support them claims. My understanding is that PAE allows a 32-bit OS access to 64GB of RAM, not 128GB. If more than 64GB is supported by PAE, could someone please update the article and state the maximum amount of RAM that can be supported by PAE. If those versions of 32-bit Windows can support 128GB of RAM, can you please provide a reference. Thanks. TurboForce (talk) 02:21, 7 January 2012 (UTC)

Microsoft states that there is only 64 Gb supported in any 32 bit Windows: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778%28v=vs.85%29.aspx#physical_memory_limits_windows_server_2003_r2 — Preceding unsigned comment added by 31.210.209.36 (talk) 11:28, 18 November 2013 (UTC)

Athlon? Really? All of them?

I just slapped a dubious tag on the word Athlon in this bit in the lede:

such as the AMD Athlon and later AMD processor models.

I'm fairly certain I've seen Athlon CPUs that reported they didn't support PAE. Does anyone have the required references to address this? (no pun intended...) Jeh (talk) 18:28, 25 February 2011 (UTC)

Hmm, yep...

C:\Documents and Settings\jeh\Desktop>ProcFeatures.exe
Process Feature v1.10
Copyright (C) 2005 Mark Russinovich
Sysinternals - www.sysinternals.com
AMD Athlon(tm) MP 2800+
x86 Family 6 Model 10 Stepping 0, AuthenticAMD
No Execute Protection:              N
Physical Address Extensions (PAE):  N
Floating point emulation:           N
Pentium Floating point errata:      N
RDTSC (Cycle counter):              Y
MMX Instruction Set:                Y
3D Now Instruction Set:             Y
SSE Instruction Set:                Y
SSE2 Instruction Set:               N
C:\Documents and Settings\jeh\Desktop>

That's of course OR. But it ought to be enough to spur a search for authoritative docs. Clearly PAE came in with some version of AMD CPUs, the first Opterons if not earlier. The question is, how much earlier? These particular 2800MP's are of the "Barton" series, btw. Jeh (talk) 22:43, 25 February 2011 (UTC)

You might want to check whether there is a BIOS setting that disabled PAE. Here are a bunch of /proc/cpuid dumps showing AMD processors at least as early as 6-1-2 supported PAE. ([3] and [4]) 206.248.137.124 (talk) 19:44, 22 March 2011 (UTC)

from other side "grep flags /proc/cpuinfo"

flags  : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow ts — Preceding unsigned comment added by 178.7.162.218 (talk) 14:38, 2 September 2011 (UTC)

Whoa Jeh, you need(ed) a hardware donation... I remember using Athlon MPs around 2000-2001. Don't recall if they had PAE, but they didn't have NX bit. I suspect AMD added PAE when they added NX as well. Someone not using his real name (talk) 21:29, 1 March 2014 (UTC)

By the way, this is pretty weird. According to cpu-world, all of these Althon MP supported PAE, including the oldest 1.2Ghz one [5] and the 2800+ that Jeh has [6]. I'm guessing the site is wrong. Someone not using his real name (talk) 22:09, 2 March 2014 (UTC)

The thing is that even the server boards for the Athlon (MP) only supported up to 4 GB of RAM because of the 762 northbridge. AMD-762™ System Controller (p. 2): "Supports up to 4 Gbytes of memory". So even if the CPUs had PAE support or not (it's still not clear how many address lines they had) it didn't really matter. They had no NX bit either, so there was no real advantage to using PAE on them. Someone not using his real name (talk) 00:54, 3 March 2014 (UTC)

If you "guessed that the site was wrong," why did you then use it as a ref in the article? Seems like we should dig out the contemporaneous AMD documents. (And please, no more hardware donations! I keep old stuff around because I work on code that has to be tested on it.) Jeh (talk) 02:06, 3 March 2014 (UTC)

Large page size with PAE

An IP put a question in the article text, which I just reverted - however the question deserves a better answer than can fit in the edit comment.

The IP was questioning whether large pages under PAE are really 2 MiB instead of 4 MiB. The short answer is: yes, they are.

The explanation: Without PAE, the high order 10 bits of the virtual address are used to index into the page directory. If the PD entry has the "large page" flag set, then it indicates a large page. There are 22 remaining bits of the virtual address to form the "byte within page"; with 22 bits you can count to 4 mebibytes. So without PAE, large pages are 4 MiB.

But with PAE, it takes 11 bits of the PTE to get to the PDE: Two bits to index into the PDPT, and then nine bits to select a PDE. So 11 bits of the virtual address are already used, leaving 21 bits for byte-within-page. That allows only two mebibytes within the page, not four.

If appropriate references can be found for this (or if it can be plausibly justified that this is more at the level of "2+2=4" than at the level of original synthesis) then some form of this explanation should probably be added to the article.

I hope this helps. If this explanation is unclear, please follow up here. Jeh (talk) 00:18, 2 October 2011 (UTC)

Windows memory limits table

"The following table shows the hard memory limits for release versions of Microsoft Windows on the x86/x64 architecture"

Why we need this large table here? The x64 column is not applicable to PAE because PAE is x86-only mode. Also, this large table looks like advertising, and there is only source - Microsoft itself. I suggest changing the table to 1-2 sentences just to say that most 32-bit versions are limited to 4G and some overpriced versions are allowed to used up to 32 GB. And I think we can also mention that there is a binary patch possible to push limits. `a5b (talk) 19:13, 19 December 2013 (UTC)

Oppose. Microsoft is a suitable reference for its product limitations. The table shows some MS silliness. The proffered replacement carries a POV. Glrx (talk) 23:43, 20 December 2013 (UTC)

There can be better sources then MS for microsoft marketing limitations (and for patching) and there can be better place to write about them. Why we needed x64 column here, in x86-only extension? `a5b (talk) 02:12, 21 December 2013 (UTC)

The issue of whether or not PAE is part of x64 is not straightforward. The processor must be in protected mode with paging and PAE enabled before enabling long mode, and the PAE bit must not be cleared while in long mode. Furthermore the page table structure in long mode is quite clearly an expanded version of that under PAE. When this came up before it was decided to regard long mode as including PAE. I wouldn't mind revisiting that, but as things stand now, it is consistent with other WP material to include x64 here.

Microsoft clearly says that PAE is not used in x86 OS: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366796(v=vs.85).aspx "PAE is used only by 32-bit versions of Windows running on x86-based systems." `a5b (talk) 16:30, 26 December 2013 (UTC)

And AMD clearly says, in AMD64 Architecture Programmer’s Manual, Volume 2: System Programming: "Long mode requires the use of page-translation and the physical-address size extensions (PAE)" (page 4), "PAE is always enabled in long mode" (page 130), etc. x64 versions of Windows do of course run in long mode. The underlying truth behind the Microsoft statement is that the /PAE boot option has no effect on 64-bit versions of Windows. Jeh (talk) 07:25, 27 December 2013 (UTC)

As for "better sources", I don't see it. The RAM limits are simple statements of fact. They require no interpretation. Hence a primary source is just fine. Jeh (talk) 04:13, 21 December 2013 (UTC)

AWE again

The article includes the claim

User programs in a 32-bit Windows system can access physical memory above 4 GB 
via the Address Windowing Extensions API.

I just added the "in a 32-bit" provision because in a 64-bit system accessing RAM above the 4 GB boundary is just expected and unremarkable. (And I just took it out again, for reasons described below.)

However, this fix is really not correct on the one hand - you can use the AWE APIs on 64-bit systems, and even in 64-bit apps. And two, it really doesn't go far enough. Here's why: The AWE APIs include no provision for mapping to any particular physical addresses, nor to physical addresses above the 4 GB boundary. When using AWE, you ask for a bunch of pages of RAM with VirtualAlloc with the MEM_PHYSICAL option, and (if that much is available) it gets assigned to your process. If your system supports RAM above the 4 GB address, some of this RAM might be at high addresses, some not - just like RAM allocations due to ordinary paging. Then you can map it (that is, create virtual addresses that translate to those pages of RAM) with e.g. MapUserPhysicalPages. Later you can unmap it and then call MapUserPhysicalPages again to map to some other set of RAM pages that you allocated with a different call to VirtualAlloc.

At no point do you, or can you, ever ask for RAM that happens to be at any particular address, or at addresses above 4 GB. It is entirely possible that all of your AWE allocations of RAM might be fulfilled by RAM at addresses below 4 GB... if you don't ask for much.

Conversely, even in a 32 bit system it is commonplace for an app's normal paging behavior to result in use of RAM at addresses above 4 GB. On, of course, Windows systems that support RAM at such high addresses (i.e. not client versions since XP SP1)... but this requirement applies to AWE as well.

For that matter you can use the AWE APIs on 32-bit systems running without PAE. There's usually not much point, because there won't be enough RAM to make use of AWE productive, but they'll work as long as you don't try to allocate much RAM.

What AWE is about is allowing a 32-bit app to access more than its usual 2 GB limit of virtual address space (which limit, yes, can be 3 GB or 4 GB in some circumstances) by taking a portion of that VAS and remapping it to various sets of physical pages at various times. You still only have 2 (or 3 or 4) GB of VAS, but you switch the mapping of a portion of that VAS among various sets of physical pages.

The more I think about it, the more I think there really isn't a way to salvage the above claim. AWE is just not about accessing RAM at high physical addresses. It's just that if your system isn't able to access RAM at high physical addresses (either because of license limits or because it's a 32-bit system not running with PAE) there likely isn't enough RAM available to make AWE useful. Jeh (talk) 15:10, 28 January 2014 (UTC)

Hi. If there is no way to salvage, revert. (I just did.)

Best regards, Codename Lisa (talk) 20:04, 28 January 2014 (UTC)

The version you reverted to has the same problem. AWE is not about "accessing RAM above 4 GB". Our own article on Address Windowing Extensions covers it pretty well, and you'll notice it doesn't mention accessing RAM that's at high addresses. Jeh (talk) 20:09, 28 January 2014 (UTC)

Deleted. Best regards, Codename Lisa (talk) 20:31, 28 January 2014 (UTC)

Thanks for your support :) I've decided that sometimes it's appropriate to ask "this change makes sense to me, but does it to anyone else?" before just going in and being bold. Jeh (talk) 12:36, 29 January 2014 (UTC)

So do I. But please don't be surprised if you discovered that your opinion of what falls into this category is radically different than person with same opinion sitting next to you. In my case, content without source can be challenged and deleted. Best regards, Codename Lisa (talk) 08:19, 30 January 2014 (UTC)

Pentium II non-Xeon

According to [7], p. 52, it did not support PAE. Is it true? I once had PII-266 but it's ancient history, so can't check myself. Someone not using his real name (talk) 22:52, 1 March 2014 (UTC)

It probably doesn't really matter because the typical PII chipset (440BX) supported only 1GB of RAM anyway [8]. Even for the Xeon, only the 450NX supported 8GB, while the 440GX supported only 2 GB (same ref). Someone not using his real name (talk) 02:55, 2 March 2014 (UTC)

Are there any chipsets that actually allow this to be useful?

My understanding of this is that PAE is useless in practice, because the motherboards for PAE-32-bit CPUs never support more than 4GB. So although the CPU and OS could cope with more physical RAM, the chipset makes this unusable. Is this correct? Are there any desktop or laptop machines for which there is an exception to the rule "32-bit CPU means <= 4GB RAM" ? — Preceding unsigned comment added by 46.65.232.242 (talk) 17:13, 18 April 2014 (UTC)

You're mistaken. Heck, the comment section just above this one mentions the 450GX, which was for the Pentium III-era Xeon. A quick check of List of Intel chipsets will show you several chipsets that supported >4GB RAM for 32-bit CPUs, one as far back as the Pentium Pro. I think the most recent would be the E7500 group. But they were not put on desktop class motherboards and certainly not laptops. They were for servers and workstations. Jeh (talk) 17:30, 20 July 2014 (UTC)

Why there are only 52 bits used for addressing in PAE mode?

First, and most important of all, as we know in PAE mode physical memroy address is aligned in 4KiB boundary. So the 12 bits of right most bits are implicitly 0, existing but not presented in the PDE, PTE, PPDE and so forth. Even though they are not presented, but the remaining bits position are corresponding to them in PDE, PTE, PPDE and so forth, leaving the 12 right most bits used for flags. This is important, and always arise confusion. Now you might ask why there is only 51 or 52 bits for addressing physical memroy but not the whole 64 bits. Yes, it should have been extended into 64 bits, but as the first PAE implementation, no needs for 64 bit address, so the 12 left most bits( or 12 most significant bits) are reserved for later use. NX bit in AMD64 is an example. CPU manufacture wants to use these bits for special feature rather than addressing the physical memory. So 64 - 12 = 52, yes, 52 bits are the upper boundary for the current physical memory addressing, not 51 bit. For this you can reference Page 126, AMD64 Architecture Programmer’s Manual Volume 2: System Programming(24593.pdf). —Preceding unsigned comment added by Janagewen (talk • contribs) 13:51, 9 January 2009 (UTC)

I think you are confused on one point: The NX bit is not part of the physical address. It is in the page table (or page directory, etc.) entry, wherein it is just as permanently reserved as the low-order 12 bits (page present bit, read-only bit, privileged access bit, etc.). Although the NX bit is indeed interpreted by the hardware, 11 more bits at the high end are also reserved by the architecture spec for OS use. (Windows uses them for a "working set list index.") Therefore the physical page number field of the PTE can never grow beyond bit 51. 64 bits total - 12 low-order bits - 12 high-order bits = 40 bits of physical page number from the PTE, plus 12 bits of byte offset from the original virtual address, means we have an absolute maximum possible 52 bits of physical (RAM) address. Now of course current implementations are not supporting anything like this many bits, but it is not because the 12 most significant bits are reserved for special non-address-bit meanings; it is just that nobody thinks there is a need to provide for addressing more than 4.5x10¹⁵ bytes of RAM (4.5 million gigabytes) in anything like the immediate future. Perhaps indeed someone will come up with a special meaning for bit 62 or bit 61 but I doubt seriously that we'll be pushing 52-bit physical addresses, let alone 60-bit physical addresses, by that time. Jeh (talk) 12:15, 18 June 2009 (UTC) (The preceding comment has been edited by the original author. New or changed text is in bold, removed text is in strikeout. See my next comment below, 22:49, 16 February 2014 (UTC), for more.) Jeh (talk) 22:52, 16 February 2014 (UTC)

I think the following sentence in the article is not explaining well why the physical address is limited to 52 bits: "Because the 12 least significant bits of the page table entry's 64 bits are either similar flags or are available for OS-specific data, a maximum of 52 bits are available to address 2⁵² bytes, or 4 petabytes, of physical memory." The limitation is not because the 12 least significant bits are used for flags or OS-specific data, but because the 12 _most_ significant bits are either reserved or in case of bit 63 used for the NX flag. Seipher (talk) 20:47, 16 February 2014 (UTC)

It's actually both (12 high and 12 low), resulting in the PTE supplying only 40 bits of physical address and the original VA supplying 12 more. You're correct though that the graf as written is both misleading and incomplete. So is my comment above of 18 June 2009. I've fixed the above, and will fix the article unless you want to. Jeh (talk) 22:49, 16 February 2014 (UTC)

...and, the article is updated. Comments? Jeh (talk) 00:17, 17 February 2014 (UTC)

Looks correct to me. Thanks for the quick update. Seipher (talk) 01:45, 20 February 2014 (UTC)

The very reason why there are only 52 bits used for addressing in PAE mode is that the very first 8086 processor using segmentation to address physical memory, where segment register such as CS is 16bit but referring 20-bit long segments after shifting 4 bits to the left. Keeping this schema, if there were 32bit real mode, then 20 bits (used for referring segments) + 32 bits (base address) = 52 bits (for logical addresses). But this is not the truth, but just a guide to draw the reason why. In Intel64 and IA-32 Architectures Software Developer's Manual, it says M is an abbreviation for MAXPHYADDR, which is at most 52, where M is used in PDE, PTE and PPDE without further explanation. But I don't believe, for AMD64 architecture, that would be the extreme limit for the physical addressing. If further AMD64 processor gets rid of legacy mode completely, then there would potentially 63bits for addressing physical memory rather than 52bits, like it in Itanium architecture. That might be wrong, but just put a stop to end this topic. Janagewen (talk) 14:27, 20 October 2014 (UTC)

Sorry but that makes no sense. One, there is no segmentation in long mode. Two, the size of a logical address is not 52 bits; it is currently 48 but could be anything up to 64 bits. Three, there is no fixed relationship between size of logical and physical address, so your little calculus of 20+32=52 bits has nothing to do with physical address size. The 52 bit limit comes from: 12 bits come from the linear address (the offset in the page), and 40 bits from the PTE. The reason it is only 40 bits from the PTE is that the PTE is 64 bits wide and 24 of the bits are designated for other purposes; about half of them interpreted by the MMU and the others reserved for use by the OS. If for some reason we need larger physical addresses in the future a new "long mode PAE" could be defined with a different page table format. It would have nothing to do with getting rid of legacy mode. So, yes, you're wrong. And the topic was already quiescent as of eight months ago. Jeh (talk) 17:36, 20 October 2014 (UTC)

Yeah, that's a great explanation. Jeh, anyway, thank you for your reply. Janagewen (talk) 23:53, 20 October 2014 (UTC)

I thought it was sufficient when I gave it eight months ago (22:49 pm, 16 February 2014 (UTC)). Jeh (talk) 00:10, 21 October 2014 (UTC)

This topic was created by me, the very "done" or "archive" should I make or any wiki administrator rather than someone else. Janagewen (talk) 22:44, 22 October 2014 (UTC)

The section creator has no special rights of ownership, and it had been quiet for eight months. Had archiving been enabled previously it would have been archived months ago and the recent pointless addition would have been avoided. If you really care about the integrity of the material here you could improve it by applying the <s> strikeout </s> tag to your (well-intentioned but wrong) entry of 14:27, 20 October 2014 (UTC). After that, please stop contributing to this section and it will be archived automatically in 30 days. Jeh (talk) 01:41, 23 October 2014 (UTC)

It seems that me and my topic is a shit, but who are you on Wikipedia.org, Jeh? For your airy attitude towards everything that I post on wiki, I am tired of. I just wish this topic could be kept here for someone else who is intelligent enough to make an even proper answer to the ones who have the similar question too... Evaluate word phrase "human right", Jeh! Janagewen (talk) 03:09, 23 October 2014 (UTC)

Your section is not "shit"; it started a discussion that resulted in an improvement to the article page. However the discussion had been dormant for eight months, so why you would now add another comment "to put a stop to end this topic" (when it was already long ended) was, and remains, a mystery. In general we don't resurrect old threads on talk pages; in fact, one reason the auto-archive bots exist is to help discourage that practice.

Regarding keeping the topic here, remember that talk pages are supposed to be used for one thing: Discussing possible improvements to the article. If the discussion results in consensus that the article should be changed, then the info goes in the article, and the article is the long-standing record. Either way there is not often a good reason to keep a discussion on the talk page long after a conclusion is rewached. It is just not the purpose of a talk page to provide supplemental information, to "explain the same thing a different way," provide an FAQ, etc., to readers. (Exceptions exist where different editors make the same mistakes over and over again; see for example the talk page header at talk:VHS, concerning the mistaken retronym "Vertical Helical Scan".)

Regarding your annoyance: What are we (I'm not the only one who's corrected you) supposed to do when you post wrong information? Not correct it for fear that you'll feel bad? Wrap our corrections in crap like "Extreme apologies, but I feel I must offer a suggested improvement to what you wrote, as I feel you have exhibited a very small and completely understandable error..."? Yes, I can be pretty brusque... but nobody here has time to bend over backwards to avoid hurting your feelings. Look, everyone who edits here is wrong fairly often. We get corrected, and we learn to do better research before posting. (And we learn to not post at all if we already know we have to add disclaimers like "this might be wrong". WP is not the place to post material that you are unsure about,... unless of course it's clear that you're asking a question, and asking for either confirmation or correction. ) Jeh (talk) 21:53, 23 October 2014 (UTC)

Professor Jeh, if you don't have time, never waste your time. Janagewen (talk) 22:56, 23 October 2014 (UTC)

{{done}} Janagewen (talk) 00:45, 24 October 2014 (UTC)