Talk:X86-64

Redundant lists of implementations?

X86-64#AMD64 lists AMD's AMD64 processors at the beginning and also in the "Implementations" subsection. The same is true for Intel's Intel64 processors in X86-64#Intel64 and its "Implementations" subsection. Should one of each of those pairs be removed? Guy Harris (talk) 23:07, 14 February 2015 (UTC)

Hello! That's a good point, went ahead and deduplicated the content. Please check it out. — Dsimic (talk | contribs) 23:21, 14 February 2015 (UTC)

Looks good. Jeh (talk) 23:50, 14 February 2015 (UTC)

Would a list like the one that used to be at the beginning of X86-64#Intel64 be better in its "Implementations" subsection? The AMD list just goes by brand names; the Intel list breaks things up by a combination of brand names (Atom) and microarchitecture, but perhaps something such as

Intel's processors implementing the Intel64 architecture include the Pentium 4 F-series/5x1 series, 506, and 516, Celeron D models 3x1, 3x6, 355, 347, 352, 360, and 365 and all later Celerons, all models of Xeon since "Nocona", all models of Pentium Dual-Core processors since "Merom-2M", the Atom 230, 330, D410, D425, D510, D525, N450, N455, N470, N475, N550, N570, N2600 and N2800, and all versions of the Pentium D, Pentium Extreme Edition, Core 2, Core i7, Core i5, and Core i3 processors.

would work? Guy Harris (talk) 01:06, 15 February 2015 (UTC)

Hm, a more detailed breakdown we have in the article might actually be beneficial, but then again, the version you've proposed above reads much better. While thinking a bit more about it, your version would actually be better; for example, we'd also have to mention Xeon CPUs in the last bullet point, and that would be super redundant. So, I'd say you should go ahead and put your version into the article. — Dsimic (talk | contribs) 01:36, 15 February 2015 (UTC)

Done, but there's still redundancy in there; some of the material is historical and perhaps should be moved to the History section. Thanks for all your work on this! Guy Harris (talk) 01:55, 15 February 2015 (UTC)

Ah, I did nothing special, thank you for all your hard work! This edit should take care of separating most of the historical data and actual Intel 64 implementations. — Dsimic (talk | contribs) 02:52, 15 February 2015 (UTC)

Paging and x86-64

This is quite an interesting and important thing which might always confuse beginners trying to get in touch with x86-64 architecture. Some might confuse and mistake x86-64 architecture is an 48-bit architecture, no, that is absolutely wrong. x86-64 is a real 64-bit architecture, 64-bit(48-bit implemented) virtual address and 52-bit(48-bit implemented) physical address for AMD64, 64-bit(48-bit implemented) virtual address and 46-bit(fully implemented for latest Xeon processors) physical address for Intel64. 64-bit virtual/linear address is further paged into four levels, the top level is PML4, Page-map level-4, ranging from 9-bit (48-bit LA) through 25-bit (64-bit LA), leaving other three levels as 9-bit each for walking through a 4-KiB (12-bit) page. So if future x86-64 processors could fully implement 64-bit virtual address, this paging schema would not be changed. For AMD64 processor, under legacy mode, it could address up to 40 or 48-bit physical space when PAE enabled.

Another thing should also be paid attention to, the PAE capability is irrelative with it of IMC, Integrated Memory Controller. The actual maximum memory support is much less than it, but large physical space could enable devices to map their resources into this space, making expanded memory possible too. — Preceding unsigned comment added by 221.9.23.11 (talk) 02:09, 15 February 2015 (UTC)

Hello! Umh, sorry but I'm having slight difficulties understanding what are your actual suggestions on improving the article? Just as a note, talk pages should focus on article improvements; please see WP:NOTFORUM for further information. — Dsimic (talk | contribs) 02:56, 15 February 2015 (UTC)

No, the main article should also talk about something within this section. OK, guys, this is Janagewen! Would you please lock all the IP addresses within my reach. Then I would not be able to visit Wikipedia.org website. If you could help me lock all the IPs, I would say thank you to you guys! 221.9.23.11 (talk) 03:08, 15 February 2015 (UTC)

Nobody is claiming it is a 48-bit processor or that it is not a "real 64-bit architecture". However, translation of more than 48-bit virtual addresses will almost certainly involve a change to the page table structure. I would even suggest that anyone who suggests otherwise does not really understand the ramifications of what they're claiming.

The PML4 at present can only be 512 entries long, as it is indexed by only 9 bits (bits 39 through 47 of the v.a.). Now let's suppose we allow 64 bits of v.a. with no change to the page table hierarchy. Then the index value to the PML4 table would be 25 bits wide (the 9 bits currently implemented, plus 16 more). To allow all possible index values the PML4 table would therefore have to be 2²⁵ or 32x1024² entries long. Since each entry is eight bytes this would occupy 256 MiB. That's 256 MiB of not-pageable, physically contiguous RAM. That seems like rather a large memory requirement, even with modern multi-GiB RAM configurations, especially since all three major OSs that run on x86-64 use a different PML4 table for each process. With just 16 processes you would need 4 GiB of RAM just for the processes' PML4 tables. I don't think that is a viable approach.

No, the most reasonable way to implement more bits of VA would be to add more levels to the page table hierarchy, exactly analagous to how the PML4 table was added to the three-level PAE design. The most obvious design would have a 5th-level table (PML5?) indexed by bits 48 through 56 of the VA, and a 128-entry 6th-level table, with its PA in CR3, indexed by bits 57 through 63. (Maybe when they do that they can get rid of the silly special names for each level in the hierarchy and just call them page tables levels 1 through 6!) Jeh (talk) 10:34, 15 February 2015 (UTC)

No, completely no! There would be no PML5 or PMLn. — Preceding unsigned comment added by 192.154.200.6 (talk) 22:58, 28 September 2015 (UTC)

Why not? It would certainly work. How do you know this with such certainty? Jeh (talk) 05:26, 1 October 2015 (UTC)

... actually it doesn't matter. All of this is speculation. WP doesn't publish editors' speculation. I'll be archiving this section as irrelevant to improving the article. Jeh (talk) 05:26, 1 October 2015 (UTC)

Hello, 192.154.200.6. There is only PML4, and whether there would be PML5, we are not so sure at this moment. Hello, Jeh. We have no ideas whether it would certainly work. Do you have any book or document to prove your words? EhietGeht (talk) 06:15, 1 October 2015 (UTC)

Please. This is a standard technique for implementing sparse arrays, taught in every data structure class, implemented in many many cases. Specifically for address translation, some older processors (like the VAX) use a single level of PT lookup. x86 without PAE uses two levels. x86 PAE uses three levels. x64 long mode, aka IA-32e paging by Intel's naming, uses four levels. There is no reason to think that the technique would magically stop working at level five or six. I'm not claiming it's the best way to implement 16 more bits of virtual address (there might be other methods that would scale better) but yes, it would certainly work. It already does. And it would be a simple set of changes to existing code. Jeh (talk) 05:20, 2 October 2015 (UTC)

Hello, Jeh. We have no information on that right now, and we do not speculate any possibility. EhietGeht (talk) 22:30, 2 October 2015 (UTC)

Beg pardon, but we don't include speculation in articles. This is a talk page. I was responding to a claim by 221.9.23.11 that x64's current address translation scheme could support 64-bit virtual addresses as x64 is currently defined, specifically

"So if future x86-64 processors could fully implement 64-bit virtual address, this paging schema would not be changed. 221.9.23.11 (talk) 02:09, 15 February 2015 (UTC)"

That was, and remains, a false claim. My suggestion that more levels could be added to the PT hierarchy was an example of the sort of thing that would have to be done for x64 to implement 64-bit VAs. Talk pages are for discussing improvements to the article, but that "restriction" is interpreted quite broadly. It does include discussion of why an editor's claim is wrong. It is much better to head off such things before they get into articles. Jeh (talk) 22:49, 2 October 2015 (UTC)

btw, thank you for using regular talk page formatting! That did not go unnoticed. Jeh (talk) 22:49, 2 October 2015 (UTC)

Hello, Jeh. We do not have any idea about that claim, and we do not either speculate its correctness. EhietGeht (talk) 23:03, 2 October 2015 (UTC)

On the contrary, we have a perfectly good "idea" about the claim. The fact that the paging scheme defined for x64 is limited to 48-bit virtual addresses is exactly described in both AMD and Intel's docs (as profusely linked already). The diagrams of address translation in those documents clearly show that bits 48 through 63 of the VA do not participate in address translation in the current scheme. Ergo, to translate even one more bit of VA, let alone 16 more bits, the scheme would have to change. QED.

As for what "we do not" do, you are free to refrain from what you regard as "speculation." For myself, I disagree with that characterization of my responses, nor does "WP does not publish speculation" strictly apply to talk pages. I acknowledge that you have a different opinion. Let's leave it at that, please. Jeh (talk) 23:24, 2 October 2015 (UTC)

Hello, Jeh. I have to make clear that everything you mentioned here or someone else could only be a speculation. Even let me to speculate your mentioned PML5 or PMLn are far more practical than what we expect. At least at this moment, we do not want to waste that huge cost for additional paging level(s). So we do not have any word around that presumption. EhietGeht (talk) 00:27, 3 October 2015 (UTC)

Hello, 221.9.23.11. We have no ideas that if future x86-64 processors could fully implement 64-bit virtual address, this paging schema would not be changed, because there is no documents to prove what you said. But the actual maximum memory support is much less than it is incorrect, the physical memory could be supplemented with a second processor attached on the Hyper Transport Bus, the MPS BIOS would map the physical memory space to these different physical regions. So no matter 40-bit or 48-bit physical address space could possibly be reached without any doubt. EhietGeht (talk) 00:49, 3 October 2015 (UTC)

Shall We Further Extend the Section Intel 64 History?

“ When engineers at Intel started with a “clean sheet of paper” in 1991, it was no surprise that two schools of thought emerged: one to extend CISC IA-32 instructions to support 64-bits, and another to introduce a cleaner RISC style instruction set with the 64-bit support (while maintaining the old instructions for compatibility). While we settled on the RISC approach for a new 64-bit architecture, the attractive idea of extending IA-32 for 64-bit addressing was revisited several times within Intel. It turns out that, for all the marketing charm that a simplistic idea like adding 64-bit addressing to IA-32 holds, in reality that approach would not yield the long-term value we needed. We didn’t figure it out right away, but the RISC approach faced the same reality. ”

The above words are directly referenced from Foreword of Itanium Architecture for Software Developers by Walter Triebel, Intel Press 2000, ISBN: 0970284640. Focusing on the date, 1991, possibly guesses would easily be put to consideration of Intel's own 64-bit version of IA-32 more than a decade before Yamhill rumoured. 175.17.63.223 (talk) 01:52, 15 September 2015 (UTC)

I think we would need something a lot more specific than this. And there are a lot of problems with it, even just as it is now. For one thing, anyone considering extending x86 to 64 bits is clearly not starting with "a clean sheet of paper"! Also, this narrative is belied by our own article on Itanium, which states that Itanium development began at HP with "investigations" in 1989, and that HP's partnership with Intel on what was to be called Itanium didn't happen until 1994. Now, hmm... the article that text references actually claims the latter date is 1993. But still, that puts some doubt into the 1991 claim. Or at least into exactly how specific were these two "schools of thought" at Intel in '91. What exactly happened at Intel in 1991, or at any of the later "revisits"? Did someone just write "x86 extended to 64 bits" on a whiteboard once or twice and each time say "nah, that's stupid" and cross it off? Or did they investigate the concept without defining it in much detail? Or did they (during any of those visits) go as far as spec'ing out a proposed 64-bit ISA that would be recognizable as an ancestor of Intel64? If not the latter (and, of course, we'd need good solid references) then I don't think it belongs in a history of Intel 64. Maybe in a more-generic history of 64-bit computing? Jeh (talk) 06:13, 4 October 2015 (UTC)

x64

It should be clearly noted that the term "x64" is wrong and only used by two companies. The correct terms used by Intel and AMD are "x86_64" and "amd64". 193.166.70.166 (talk) 12:51, 30 September 2015 (UTC)

Incorrect on several points, I'm afraid, particularly the notion that "x64" is somehow "wrong". It isn't specific to either Intel or AMD but that doesn't make it wrong.

“ x64 is a generic name for the 64-bit extensions to Intel's and AMD's 32-bit x86 instruction set architecture (ISA). AMD introduced the first version of x64, initially called x86-64 and later renamed AMD64. Intel named their implementation IA-32e and then EMT64. ”

That's from Introduction to x64 Assembly, an article at intel.com. Jeh (talk) 13:46, 30 September 2015 (UTC)

Hello, 193.166.70.166, thank you for figuring out x64. But your description is incorrect. Intel uses IA-32e while AMD uses AMD64 in their official documents. So many software have already used x64, x86-64 and x86_64 to refer to this instruction set. As to the main article, because it is written by kids or hobbies rather than professionals or experts on computer science. So we could not have a fair judgement. But you are welcome to help improve it. EhietGeht (talk) 06:09, 01 October 2015 (UTC)

Intel now uses Intel64 as the marketing name, but still uses "IA-32e" internally. See section 4.5 of Intel® 64 and IA-32 Architectures Software Developer’s Manual, where they describe "IA-32e paging", but then look at the title on the cover! Jeh (talk) 04:57, 2 October 2015 (UTC)

---

1. Where does x64 come from?

Windows XP 64-Bit Edition for 64-Bit Extended System was the very first product for AMD64 architecture released in September, 2003, and it was later renamed to Windows XP Professional x64 in late 2004.

Incorrect. What Microsoft shipped in 2003 was Server 2003 for Itanium. x64 versions of Windows XP and Server 2003 didn't RTM until March 2005. I believe the term "x64", as an obvious parallel to "x86", had been used earlier. "x64" is certainly all over a lot of Linux distro file names. Jeh (talk) 22:53, 9 October 2015 (UTC)

What you said is partially correct! At least I am trying to find sourcing from forums of Intel, AMD and Microsoft! So please do not make such an irresponsible conclusion right now, ok?

Best Regards,

Aaron J. 175.17.60.184 (talk) 23:50, 9 October 2015 (UTC)

You will not find an "official" date for the "x64" term from Intel or AMD because to neither of them is it an official term. Forums are user-contributed content and are not considered reliable sources on Wikipedia. Re Windows versions, please see Timeline of Microsoft Windows. Jeh (talk) 02:46, 10 October 2015 (UTC)

No, you often fail to understand others' words, but it does not matter! The more people take part in discussion, the more reliable sources might possible be obtained. What's more, what is the source about your own viewpoint, "the term "x64", as an obvious parallel to "x86", had been used earlier.."?

Best Regards,

Aaron J. 175.17.60.184 (talk) 03:05, 10 October 2015 (UTC)

I don't have a source for the origin of the term "x64". (Which is why I said "I believe...") Perhaps you could find one. We know that both Solaris and Oracle use the term "officially" but I haven't been able to find a RS for their first use (and Sun/Solaris is now part of Oracle). It is clear the XP and Server 2003 for x64, which RTMd in 2005, were an official use, but my point is simply that the term's first use as part of a Microsoft product name cannot be used as proof that Microsoft invented the term, so we can't make that claim. Jeh (talk) 04:03, 10 October 2015 (UTC)

Through your words, I might speculate IP user, 193.166.70.166, might possibly be you. Thank you creating this discussion!

Best Regards,

Aaron J. 175.17.60.184 (talk) 04:41, 10 October 2015 (UTC)

Nope. If you'll notice, I voiced an opinion contrary to 193.166.70.166's. But by all means, if you think that, create an WP:SPI. I will be happy to see this speculation about me definitively dismissed. Jeh (talk) 06:07, 10 October 2015 (UTC)

2. What does x86-64, x64, Intel 64 and AMD64 mean?

The four words could be used to point the same thing, 64-bit processor on our desktop or laptop computers.

x86-64 is an instruction set architecture name.

x64 might be the same as x86-64.

Intel 64 is used by Intel to name their 64-bit processors and architecture on desktop, laptop computers and even workstations and servers.

AMD64 is the name used by AMD for their 64-bit processors.

3. What is AMD64 architecture?

In AMD Official documents, it is said "The AMD64 architecture is a simple yet powerful 64-bit, backward-compatible extension of the industry-standard (legacy) x86 architecture."

4. Is it the 64-bit version of the x86 instruction set?

I know many so many people will go against to me, but I have the freedom and right to make this discussion on this talk page.

According to the AMD official document, it is not strictly correct! It is said this 64-bit architecture is backward-compatible extension of x86 architecture, but not directly or indirectly saying that it is the 64-bit version of x86 instruction set. In fact, AMD64 and Intel 64 is a x86/IA-32 architecture associated 64-bit architecture. The 64-bit instruction set architecture is extended from 32-bit x86/IA-32 architecture. Neither of AMD nor Intel mentioned their own 64-bit processors are built on 64-bit version of x86 or IA-32 architecture. As a faithful wiki reader, I wish the main article could have its reservation for something not that so sure, or not that widely accepted.

Please allow me to suggest 64-bit instruction set of x86 processor. It is much better than that and also keeps the consistency with article x86.

Best Regards,

Aaron J. 119.53.106.61 (talk) 13:04, 9 October 2015 (UTC)

The wording 64-bit instruction set of x86 processor would be very confusing. To many, if it's an "x86 processor" then it isn't 64-bit. Note for example that 64-bit Windows stores 32-bit executables in \Program files (x86). If one interprets "x86 processor" to mean a 32-bit processor, which is a very common interpretation, then such a processor flatly cannot have a "64-bit instruction set". On the other hand, a 32-bit instruction set can most certainly be changed, enhanced, extended, etc., to include 64-bit support, and that instruction set implemented by a 64-bit processor. Jeh (talk) 22:40, 9 October 2015 (UTC)

No, it is not confusing at all. If x86 processor is purely a 32-bit processor, then the wiki article x86 is a confusion. Saying 64-bit instruction set of x86 processor is definitively clear, because who would think a 32-bit x86 processor has a 64-bit general instruction set? Or else it is definitively a 64-bit processor. The only thing which is not widely accepted and not recognised by neither AMD nor Intel is that 64-bit version of the x86 instruction set. At least, AMD never said something like that since 2001!

Best Regards,

Aaron J. 175.17.60.184 (talk) 23:58, 9 October 2015 (UTC)

Well, no, they wouldn't have said exactly that... since "x86", being non-manufacturer-specific, is not an AMD official term (nor an Intel official term).

I didn't say "x86 processor" is purely a 32-bit processor. I said it is widely understood to be that.

Previously you noted that in an Intel book you found the text "extend CISC IA-32 instructions to support 64-bits," and now here you are claiming that the result of such an effort should not be called a "version" of the IA-32 (or, generically, x86) instruction set. In fact, these two wordings are perfectly compatible with each other.

The full details are these: An x64 processor in legacy mode (which is how they come up after a reset) supports the 32-bit x86 instruction set, with the added mechanism to switch to long mode. Once in long mode the processor then supports either the Intel64 or AMD64 instruction set depending on manufacturer (these are nearly identical), generically called the "x64" or "x86-64" instruction set. This includes "compatibility mode", a 32-bit mode available "within" long mode, which provides practically the entire 32-bit x86 instruction set to applications.

But that's a really long description, you don't put such in the article lede. For the article lede, "64-bit version of x86 instruction set" is an easy way to introduce the concept and perfectly suitable for the lede; the details are for the article body. Jeh (talk) 03:03, 10 October 2015 (UTC)

What is 64-bit version of x86 instruction set? Or a bit more exactly, what is the x86 instruction set? Is it a 16-bit, 32-bit or 64-bit instruction set? Is that the original research of yours or someone else, as you mentioned everywhere on wiki, we need enough sources to prove this view point!

Best Regards,

Aaron J. 175.17.60.184 (talk) 03:53, 10 October 2015 (UTC)

As you said: AMD documents state " "The AMD64 architecture is a simple yet powerful 64-bit, backward-compatible extension of the industry-standard (legacy) x86 architecture." That's a "horse's mouth" source. That and the statement you're arguing against are semantically equivalent; we do not need to find sources for exact phrasing and word choice. If you're quibbling that "version" is something different enough from "extension" to need another source, you are simply wrong; you are arguing over a distinction that does not make a difference. (Most "extensions" can indeed be called "versions", but not every "version" is an "extension.") Jeh (talk) 04:12, 10 October 2015 (UTC)

What's more, you might misunderstand others, for "and now here you are claiming that the result of such an effort should not be called a "version" of the IA-32...". I am very sorry, I do not know what make you embrace that kind of idea. Saying one thing is some a version of another thing is not a casual job, one should put much more considerations to it. Because it is saying that it is some a form of another thing rather than some parts of another thing. If x86-64 were 64-bit version of x86 instruction set, then these two instruction sets must be equivalent to some extends only on different forms. Segmentation is the prominent and major architecture feature of x86 processors, but lacks in x86-64. x86-64 does not only expand the x86 registers to 64-bit but also introduces additional RISC-naming convention registers. These two points distinct x86-64 from x86, making them both not that equivalent. And most of all, there is no documents from Intel and AMD, to state that it is the 64-bit version of IA-32 or industry standard x86 architecture. Only for the latter reason, we could not invent some a name or description to confuse the two similar but might not possibly same things.

Best Regards,

Aaron J. 175.17.60.184 (talk) 04:32, 10 October 2015 (UTC)

The phrase from the AMD doc that you previously quoted is completely sufficient reference. The points you raised such as elimination of segmentation (um, well, but segments are still operational in compatibility mode! They have to be, for 32-bit protected mode code to work right) and additional registers are entirely compatible with the word "version". I think the real problem is that you do not understand the full scope of meanings to which "version" can refer: It can include things added, things left out, existing things changed. If anything we could argue that the AMD doc's use of "extension" is misleading (one of your favorite words) because if we remember that segmentation is not present in long mode, the long mode architecture cannot be said to be a pure "extension", since it left some things out! Bah. There's no problem with the existing text. Jeh (talk) 04:59, 10 October 2015 (UTC)

As someone else, your reply is well received by me! But there is still large room for ones besides you and me, and they are welcome to...

Best Regards,

Aaron J. 119.53.106.186 (talk) 07:49, 10 October 2015 (UTC)

Yes, I'm welcome to agree with Jeh 100% and Janagawen 0%. x86 is a family of instruction sets (16-bit x86, 32-bit x86 or IA-32, 64-bit x86 or x86-64), just as MIPS is a family of instruction sets (MIPS I, MIPS II, MIPS III, MIPS IV, etc.) and System/3x0 is a family of instruction sets (32-bit-with-24-bit-addressing System/360, 32-bit-with-24-bit-addressing System/370, 32-bit-with-31-bit-addressing System/370-XA, 64-bit z/Architecture), and so on. Guy Harris (talk) 06:56, 10 October 2015 (UTC)

Thank you for remembering my name. But the percentage that I agree with you is roughly 70%, because I agree with you that IA-32 is 32-bit version of x86 instruction set. As to the x86-64, I stick to my viewpoint (of course, you have the right to stick to your viewpoint), is merely 64-bit instruction set of x86 processor rather than 64-bit version of x86. As to the quoted, "The AMD64 architecture is a simple yet powerful 64-bit, backward-compatible extension of the industry-standard (legacy) x86 architecture.", it is clear and well-formed. After keeping the central parts, it is shrunk like that The AMD64 architecture is a 64-bit extension of x86 architecture. A 64-bit extension of x86 architecture would be interpreted like 64-bit version of x86 instruction set, this is the 30% disagreement to you.

Best Regards,

Aaron J. 119.53.106.186 (talk) 07:49, 10 October 2015 (UTC)

There exists a family of instruction set architectures that includes 16-bit x86 (as implemented in the 8086/8088, 80186/80188, and 80286), 32-bit x86 (as implemented in the 80386 and all later 32-bit processors), and 64-bit x86 (as implemented in the Opteron and all later 64-bit processors). 32-bit x86, or IA-32, was a backwards-compatible extension of 16-bit x86, and 64-bit x86, or x86-64, was a backwards-compatible extension of 32-bit x86. That family is what the x86 page covers.

Intel even spoke of "32-Bit Extensions of the Instruction Set" in their "Introduction to the 80386" document, saying

With the 80386, the 86/186/286 instruction set is extended in two orthogonal directions: 32-bit forms of all 16-bit instructions are added to support the 32- bit data types, and 32-bit addressing modes are made available for all instructions referencing memory. This orthogonal instruction set extension is accomplished having a Default (D) bit in the code seg- ment descriptor, and by having 2 prefixes to the instruction set.

so IA-32 was just like x86-64 in that regard, and there's no reason to treat them differently. The only thing that led to "x86" being used when "IA-32" was what was meant was that, when x86-64 arrived, most x86 processors were 32-bit rather than 16-bit.

There needs to be some way to refer to the entire family of instruction sets, starting with the 8086 instruction set and going all the way to the instruction set implemented by Skylake processors. If you have a better suggestion for a single name for that entire family, please suggest it; x86-64 would then be the 64-bit version of that instruction set, or the 32-bit member of that instruction set family, just as IA-32 would be the 32-bit version or member. Guy Harris (talk) 03:41, 11 October 2015 (UTC)

Thank you for your reply, Guy Harris. If you have a better suggestion for a single name for that entire family, please suggest it;, we could call both AMD64 and Intel 64 processors as x86 processors, and x86 is well accepted name for that entire family, maybe only because of that backward compatibilities on the architecture and platform. I do agree with your words and viewpoints. I just suggest that 64-bit instruction set of x86 processor is much better than 64-bit version of x86 instruction set, the most important reason is that the former description keeps the consistency of the two wiki articles, x86 and x86-64. x86-64 is a very special thing, very distinct from IA-32. In later 1990s and early 2000s, x86-64 or AMD64 is a replacement of Intel Itanium, and both of them were the successors of IA-32 or x86 products. Later time Itanium failed to successfully succeed IA-32, and AMD64 overtook it succeeding x86 (32-bit) processors. So as to x86-64 architecture, there exist two periods. The first one, independent one, a completely new architecture extending from existing x86 architecture. If Itanium successfully succeeded IA-32 processors, then AMD64 would become completely a new architecture. But Itanium failed to succeed IA-32 processors, x86-64 has its second period to succeed the x86 (32-bit) and even IA-32 by its Intel EM64T counterpart. Nowadays, both Intel and AMD's x86 processors include this extension, treating it as part of x86 processor, rather than up-side-down. As to x86-64, Intel do not give a name like 64-bit version of IA-32, and AMD does not give a name like 64-bit version of x86. So we should respect all those facts. So I made this suggestion.

Best Regards,

Aaron J. 119.53.107.229 (talk) 04:59, 11 October 2015 (UTC)

Do you also suggest that "32-bit instruction set of an x86 processor" is a better description of IA-32 than "32-bit version of the x86 instruction set"? If not, why not? I don't think the fact that "x86-64" begins with "x86" is enough of a reason. Guy Harris (talk) 04:56, 11 October 2015 (UTC)

As to IA-32 architecture, there was no alternative choices at that time. And according to Intel documentations, the 16-bit architecture evolves into this IA-32 architecture. From a practical view, under the real mode of IA-32 processors, all the 32-bit registers are visible, and the memory support could be reached into 4GB by some means. So it is definitively the 32-bit version of x86 architecture. But there would be few problems, if you say 32-bit instruction set of an x86 processor, which I do not suggest.

Best Regards,

Aaron J. 175.19.63.214 (talk) 07:55, 11 October 2015 (UTC)

No, x86-64 isn't any more special than IA-32. It's distinct from IA-32, but that's because IA-32 is a 32-bit instruction set, and x86-64 is a 64-bit instruction set; both are in the same family as the original 16-bit 8086/8088/80186/80188/80286 instruction set, namely the x86 family. That original instruction set was extended to 32 bits with IA-32 and IA-32 was extended to 64 bits with x86-64.

x86-64 isn't a replacement for Itanium, it's an attempt by AMD to compete with Intel in the 64-bit market. AMD's original press release emphasizes the "you can switch to 64-bit computing as necessary, rather than having to make a big change right now" aspect of x86-64. Intel and HP had tied up IA-64 with patents so that AMD couldn't implement it themselves. As AMD's x86-64 processors implemented x86-64 and IA-32 with the same circuitry (x86-64 being a compatible superset of IA-32), their processors were not only fast 64-bit processors, they were also fast 32-bit processors running IA-32 code - unlike the original IA-64 processors, whose IA-32 implementations were slow. So x86-64 processors could be put into ordinary PCs running 32-bit code, especially starting with the 64-bit Athlons, whereas IA-64 processors couldn't. It was intended from the beginning to be an extension of IA-32, so that x86-64 processors could be used instead of IA-32 processors, even running 32-bit-only code, just as IA-32 was intended from the beginning to be an extension of 16-bit x86, so that IA-32 processors could be used instead of 16-bit x86 processors, even running 16-bit-only code. So it's just like IA-32 in that way, and it's valid to refer to it as the 64-bit version of the underlying instruction set, just as IA-32 is the 32-bit version.

x86-64 never was "completely new" in the way that IA-64 was; it was a compatible extension, rather than an incompatible new instruction set like IA-64. The AMD press release says "AMD plans to extend the x86 instruction set to include a 64-bit mode", just as Intel said that "With the 80386, the 86/186/286 instruction set is extended in two orthogonal directions".

Intel don't call Intel 64 "a 64-bit version of IA-32", because it's a 64-bit member of the x86 family of instruction sets; it's not a 64-bit version of IA-32, because IA-32 is the 32-bit member of that family. It's a 64-bit version of x86, just as IA-32 is a 32-bit version of x86. AMD speak of it as an extension to x86, similar to the extension to 32 bits (and to an extension from 8 bits to 16 bits, but it's not clear what they're talking about there - the 8086 and 8088 were 16-bit processors, although the 8088 had an 8-bit external bus) in another press release.

So x86-64 is an extension of the x86 architecture to support 64-bit computing, just as IA-32 was an extension to support 32-bit computing.

And as for "alternative choices", there were no alternative compatible choices to x86-64, either, and if you consider incompatible choices, there were alternative choices to IA-32, such as 68k. Yes, IA-64 processors could run IA-32 applications, but not very well.

As for "the 16-bit architecture evolves into this IA-32 architecture", IA-32 evolved into x86-64, just as 16-bit x86 evolved into IA-32.Guy Harris (talk) 09:51, 11 October 2015 (UTC)

Thank you very much for your reply, Guy Harris. I almost agree with you, but "alternative choices", in my words, I mean the successors of the IA-32 architecture, Itanium and AMD64. Only one of them could be the real successor, eventually AMD64 was chosen, and it replaced the expected role of Itanium. It is right that x86-64 is evolved from industry-standard x86 architecture. But not all the evolutions generate the next generation of the original one. Spanish and Italian languages are evolved from Latin language, people speaking two languages without needing to learn each other could make simple communication without interpretation. They both belong to the Romance language family. But they are not some versions of Latin language. So evolution does really provide the path, but not the destination. Talking about versions of x86, we must research its real nature, or something differentiate it from other architectures. Something does really happen to change enable it to be an enhanced variety from its ancestor, x86. This is the special from nothing special. Another analogy, consider Japanese and Chinese languages, they both heavily use Chinese characters (kanji). Both use kanji to express the meaning directly, but for Japanese the independent atom unit is mora, written in hiragana or katakana, which could be used in turn to simulate the pronunciation of ancient Chinese, and could be associated with the correspondent kanji(s). But in Chinese language, Chinese character is just the independent atom unit. They both look similar, and large of Japanese language are evolved from ancient Chinese language, but Japanese is not some a version of Chinese. It is another language, looks like Chinese language! So saying 64-bit instruction set of x86 processor is neutral, without involving the confusions which make readers guess it is another architecture than x86.

Best Regards,

Aaron J. 119.53.108.56 (talk) 10:54, 11 October 2015 (UTC)

"I mean the successors of the IA-32 architecture, Itanium and AMD64". Itanium wasn't a successor in any technical sense; the two instruction sets are radically different. Intel intended that it replace IA-32 from a marketing point of view, but assembler programmers and compiler writers will be able to use next to nothing of their understanding of IA-32 when writing software for IA-64. AMD64, however, was a backwards-compatible extension of IA-32, adding the REX prefix to allow access to additional GPRs, IP-relative addressing modes, and 64-bit operands, and another operand-width bit in segment descriptors; in legacy mode, the values used by REX prefixes are interpreted as single-byte increment-register and decrement-register instructions, but, in long mode, they're interpreted as REX prefixes. That means you have to use multi-byte versions of register increment and decrement instructions in long mode, but that's the only incompatibility between IA-32 and x86-64 in long mode.

So x86-64 looks, with the exception of the single-byte increment-register and decrement-register instructions, like "IA-32 with more stuff added on"; that's more like "English in 1988", which lacked such important features as the noun "selfie" and the verb "google", vs. "English in 2015", with those additions, than like Spanish and Latin. No radical change there, just change like the 16-bit x86 instruction set to IA-32, with the addition of additional addressing modes, an operand-width bit in segment descriptors, etc..

"Spanish and Italian languages are evolved from Latin language" Without "backwards compatibility" - for example, both Spanish and Italian have significantly simpler grammars than Latin. x86-64 is backwards-compatible with IA-32, so that's not a good example - it's more like the difference between ARM A32 and A64, where the instructions changed in an incompatible fashion (for example, most of the conditional execution capabilities were removed in A64). IA-32 to x86-64 is more like the evolution from SPARC v8 to SPARC v9, or from System/390 to z/Architecture, or from PA-RISC 1.1 to PA-RISC 2.0, or from MIPS II to MIPS III, or from 32-bit PowerPC to 64-bit PowerPC.

And calling x86-64 the 64-bit version of x86 doesn't do anything to make people think it's another architecture from x86 - in fact, it more strongly emphasizes that it's a version of x86. Not all x86 processors support x86-64, so it's not the "64-bit instruction set of an x86 processor"; only 64-bit x86 processors support it, just as only 32-bit and 64-bit x86 processors support IA-32. x86-64 is a superset of IA-32, just as IA-32 is a superset of 16-bit x86; an x86 processor could:

• support 16-bit x86 without virtual memory (8086/8088, 80186/80188);

• support 16-bit x86 with segmented virtual memory (80286);

• support 16-bit x86 and 32-bit x86 with segmented and paged virtual memory (80386 and later IA-32-only processors);

• support 16-bit x86 and 32-bit x86 with segmented and paged virtual memory and 64-bit x86 with paged virtual memory (x86-64 processors). Guy Harris (talk) 18:24, 11 October 2015 (UTC)

---

• support 16-bit x86 and 32-bit x86 with segmented and paged virtual memory, and 32-bit GPRS are visible to 16-bit real mode (80386 and later IA-32 processors);

• support 16-bit x86 and 32-bit x86 with segmented and paged virtual memory and 64-bit x86 with paged, but almost without segmented virtual memory, and 64-bit GPRS are invisible to 16-bit and 32-bit mode (x86-64 processors).

I correct two things shown above, Obviously, Athlon 64 (AMD64) is different from 80386 (IA-32). The natural distinctions lie on segmentation and consistent architecture, which the former lacks for this 64-bit instruction set. English in 2015 dose not lack anything which English in 1988 possesses, so it is different.

Best Regards,

Aaron J. 119.53.108.56 (talk) 22:07, 11 October 2015 (UTC)

And IA-32 is different from 16-bit x86. Speaking of x86 as a "consistent architecture" is a bit bogus, given that it's an architecture with stuff added through a variety of hacks. I don't consider the lack of segmentation in x86-64 to render it somehow not "the 64-bit version of x86" - the 16-bit version has segmentation (which was used significantly), the 32-bit version has segmentation (which was used a lot less), and the 64-bit version doesn't have it in long mode, but still has it in legacy mode. I also don't consider the inability to access the upper 32 bits of the first 8 64-bit GPRs in 32-bit mode to render it not "the 64-bit version of x86". Most of the RISC instructions sets that were extended from 32 bits to 64 bits did so without a mode bit, so there's no notion of "long mode" vs. "legacy mode", and any code can get at all 64 bits of the GPRs on a 64-bit processor. What's different about x86 is that, in real mode, there's no segmentation, so there's no segment descriptor to have a default operand size, and real mode has to be compatible with real mode on 16-bit x86 processors, so the REX prefixes can't be used (they're interpreted as single-byte increment/decrement register instructions), so you can't have 64-bit operands in real mode. So x86-64 isn't as clean an extension of 32-bit x86 to 64 bits as the 64-bit versions of RISC architectures are extensions of the 32-bit versions of those architectures to 64 bits, but it's still an extension of that sort. Guy Harris (talk) 00:20, 12 October 2015 (UTC)

Hello, and always welcome, Guy Harris. You said, What's different about x86 is that, in real mode, there's no segmentation, so there's no segment descriptor to have a default operand size, and real mode has to be compatible with real mode on 16-bit x86 processors, so the REX prefixes can't be used (they're interpreted as single-byte increment/decrement register instructions), so you can't have 64-bit operands in real mode.. Thank you. Segmentation is the only method for addressing in 8086, and real mode of later x86 processors. There is no segment descriptor, but it is real mode, everything is real, real address to real physical location, without remapping or something similar (we do not talk about remapping in firmware and bridge chipsets). So segmentation addressing is its architectural feature. As to architecture consistency, for 80386 and later processors, under real mode, 32-bit GPRS are accessible, in other words, under all the operating modes (virtual x86 mode is an exception), the architecture (resources) is almost identical. As to x86-64 processor, the architecture (resources) of 64-bit mode is obviously different from it in all other operating modes. That is the obvious architectural differences between x86-64 and x86.

Best Regards,

Aaron J. 119.53.108.56 (talk) 00:44, 12 October 2015 (UTC)

A nitpick: Segmentation isn't completely absent in long mode. In compatibility mode, which is how 32-bit code runs under a long mode OS, segmented addressing is still there in all its former glory and detail. It rather has to be, or else a great deal of existing 32-bit code (any instruction that uses an explicit segment reference, any code that accesses segment descriptors, any code that writes and reads the segment registers and expects them to function) wouldn't work. So you can't say that segmentation is missing from long mode. Compatibility mode is part of long mode, after all.

Even in 64-bit mode (the other part of long mode), the FS and GS registers still exist and do support non-zero base addresses. (And of course if we're being really thorough we have to mention the four remaining bits of the CS register!) Granted this is nothing like a full implementation of segmentation, but it does mean that you can't say that segmentation is gone completely even from 64-bit mode. Jeh (talk) 06:34, 12 October 2015 (UTC)

As far as I'm concerned, "x86" is the family of instruction sets that includes the 16-bit version without an MMU, the 16-bit version with an MMU, the 32-bit version, and the 64-bit version, so the "difference between x86-64 and x86" is that x86 is the family and x86-64 is the 64-bit member of the family.

x86 has several modes:

• real mode, which is implemented by all four members of the family - including the 64-bit version, where it's a submode of legacy mode;

• 16-bit protected mode, which is implemented by the 16-bit version with an MMU, the 32-bit version, and the 64-bit version as a submode of legacy mode;

• 32-bit protected mode, which is implemented by the 32-bit version and the 64-bit version as a submode of legacy mode;

• virtual 8086 mode, which is implemented by the 32-bit version and the 64-bit version as a submode of legacy mode;

• long mode, which is implemented by the 64-bit version, with 64-bit and compatibility submodes.

Not all of the features of a version of the architecture are accessible from all modes supported by that version of the architecture. You can't do virtual-memory segmentation, or paging, in real mode. You can't do paging in 16-bit protected mode in the 16-bit version with an MMU, although you can run 16-bit protected-mode code in 32-bit protected mode, with or without paging. You can't support linear addresses larger than 32 bits in the 32-bit version. None of this makes x86-64 anything other than the 64-bit version of x86, as far as I'm concerned, and I don't see "64-bit instruction set of x86 processor" as being an improvement over "64-bit version of the x86 instruction set". For one thing, not all x86 processors support a 64-bit instruction set, only the ones that support the 64-bit version do. An "x86 processor" is just a processor that supports some version of the x86 instruction set, just as a MIPS processor is a processor that supports some version of the MIPS instruction set (32-bit or 64-bit), and a SPARC processor is a processor that supports some version of the SPARC instruction set (32-bit or 64-bit), and a PowerPC/Power ISA processor is a processor that supports some version of the PowerPC/Power ISA instruction set (32-bit or 64-bit), and a "System/3x0", or whatever it should be called, is a processor that supports some version of the System/3x0 instruction set (which includes System/360, System/370, System/370-XA, System/370-ESA, System/390, and z/Architecture, so it includes 32-bit with 24-bit physical addresses, 32-bit with 24-bit virtual addresses, 32-bit with 31-bit virtual addresses, 32-bit with multiple address spaces each with 31-bit virtual addresses, and 64-bit with multiple address spaces each with 64-bit virtual addresses; that family of instruction sets also has multiple modes, and not all of the features of a version of the architecture are accessible from all modes, and the behavior of instructions is mode-dependent, e.g. the uppermost 8 bits of addresses are ignored in the 24-bit address modes and the uppermost bit of addresses is ignored in the 31-bit address modes). Guy Harris (talk) 06:47, 12 October 2015 (UTC)

Thank you for your words, Guy Harris. Anyway, I do not go against to your viewpoints, but as the to 64-bit version x86 instruction set, I could not agree by any mean. Your words are reasonable, but I just wish reserve some room for this discussion, even without changing the main article. That is not a conclusion.

Best Regards,

Aaron J. 175.19.64.142 (talk) 07:14, 12 October 2015 (UTC)

Discuss all you want, but I can't agree with you, and, unless there's a consensus for "64-bit instruction set of x86 processor", whatever that might mean, I'll revert changes that use it in the main article. Guy Harris (talk) 07:20, 12 October 2015 (UTC)

Thank you, you are right! I do not have even to make any change!

Best Regards,

Aaron J. 175.19.64.142 (talk) 07:23, 12 October 2015 (UTC)

In Jeh's words, "If anything we could argue that the AMD doc's use of "extension" is misleading (one of your favorite words) because if we remember that segmentation is not present in long mode, the long mode architecture cannot be said to be a pure "extension", since it left some things out!", I found something incorrect. There is no misleading in AMD documentations, I have to reference it again, "The AMD64 architecture is a simple yet powerful 64-bit, backward-compatible extension of the industry-standard (legacy) x86 architecture." I have already mentioned, AMD64 is an industry-standard x86 architecture associated 64-bit architecture, even though the actual architecture is the 64-bit instruction set architecture. Comparing with the industry-standard x86 processor, the additional 64-bit part (additional operating modes) is really an extension. Again, there is no misleading at all. But this additional 64-bit part itself is not strictly a real 64-bit extension of industry-standard x86 architecture, but just extended from, to some extents. So it could hardly be the 64-bit version of x86, the reasons is what Jeh called misleading. But we could 100% make sure that it is a 64-bit instruction set of a x86 processor.

Best Regards,

Aaron J. 119.53.107.229 (talk) 00:24, 11 October 2015 (UTC)

You haven't changed any essentials from what you've said before; you have merely heaped on more layers of confusing, self-contradictory verbiage. The wording in the article is still fine. "64-bit instruction set of x86 processor" is still potentially confusing to those who do not know the correct meaning of x86. Jeh (talk) 01:21, 11 October 2015 (UTC)

OK, this is the similar response as what you did with PAE. I just said extend, but you intentionally interpreted it even further and eventually you were astray. Similar experiences dealing with talks with you is the 46-bit virtual address and segmentation. You confused virtual address and linear address, calling that 46-bit virtual address is a mistake. So I understand what you made this reply. You can still call it as 64-bit version of x86 instruction set; you can also call the paging in long mode is an enhanced version of PAE, but harmlessly, those are the words of you, not everyone's words. Even though not strictly correct, but positively ease people in confusion believe they are the truths. But all those above words tends to be meaningless towards this discussion. Jeh said "you have merely heaped on more layers of confusing, self-contradictory verbiage.", so I have to extend this discussion on extension. If a x86 processor manufacturer want to incorporate 64-bit ARM architecture into their own processors, then they introduced a new operating mode, might be called ARM64 mode. So their processors could work under two environment, 32-bit x86 and 64-bit ARM. If we say this kind of processor is a x86 processor, then this new introduced ARM64 mode is an extension. Because 64-bit ARM architecture is not x86 architecture, so we could hardly call it a 64-bit version of x86 instruction set, even though it is an extension of this x86 processor. If later all the x86 processor manufacturers produce this kind of processors, then people might call it as an extension of x86 processor, but not a 64-bit version of x86.

Best Regards,

Aaron J. 119.53.107.229 (talk) 03:13, 11 October 2015 (UTC)

And if pigs didn't have wings, they couldn't fly. See, they can't! QED. Jeh (talk) 03:34, 11 October 2015 (UTC)

Jeh said And if pigs didn't have wings, they couldn't fly. See, they can't! QED., well, I agree with it, 100%. And I would also said that even the pigs have wings, they could not fly too! Do you know why, Jeh? But I have never seen such kind of pigs! Maybe you could leave your email address or AOL, we could further discuss on pigs there, ok?

Best Regards,

Aaron J. 119.53.107.229 (talk) 03:42, 11 October 2015 (UTC)

But x86-64, unlike ARM, is backwards-compatible with IA-32, just as IA-32 was backwards-compatible with 16-bit x86 or, as Intel called 16-bit x86 in the 80386 document I cited, " the 86/186/286 instruction set". So a processor that supported IA-32 and A64 would be different from a processor that supports IA-32 and x86-64 - in fact, a processor that supports x86-64 would, by definition, support IA-32, as x86-64 is a superset of IA-32 (just as a processor that supports IA-32 would, by definition, support 16-bit x86). (In fact, a processor that supported IA-32 and A64 would be somewhat like an ARMv8-A processor, given how different A32/T32 and A64 are. :-))

So there's a very important difference here between, for example, x86-64 and A64, and it's a difference that people reading about x86 and x86-64 need to understand. Guy Harris (talk) 03:48, 11 October 2015 (UTC)

Thank you, Guy Harris, I agree with you said. I just take it as an example, assisting Jeh to understand what I was talking about. Again, thank you for your reply.

Best Regards,

Aaron J. 119.53.107.229 (talk) 03:54, 11 October 2015 (UTC)

Section Larger physical address space in legacy mode

In the section Larger physical address space in legacy mode, it is says "AMD64 extends PAE from 36 bits to an architectural limit of 52 bits of physical address.". 52-bit limitation is the architectural limitation for IA-32 architecture processor in Intel documentation. This quoted words just confuse architecture and implementation.

Best Regards, Aaron J. 175.19.63.214 (talk) 08:37, 11 October 2015 (UTC)

"52-bit limitation is the architectural limitation for IA-32 architecture processor" There's nothing about 52-bit physical addressing in Volume 3 of the Pentium Pro documentation, the Pentium Pro being the first IA-32 processor with PAE. It's x86-64 that allows 52-bit physical addresses in long and legacy modes; I won't believe that any IA-32 processor could handle 52-bit physical addressing unless I see a see a manual for such a processor ("such a processor" must not support x86-64 - if it supports x86-64, it's an x86-64 processor, not an IA-32 processor). Guy Harris (talk) 10:12, 11 October 2015 (UTC)

OK, 52-bit physical address is the limitation of what architecture? And does AMD64 change that architecture?

Best regards,

Aaron J. 119.53.108.56 (talk) 11:09, 11 October 2015 (UTC)

"OK, 52-bit physical address is the limitation of what architecture?"

For Intel, a 64-bit PTE "with IA-32e paging", according to figure 4-11 "Formats of CR3 and Paging-Structure Entries with IA-32e Paging" in Volume 3 of the Intel 64 and IA-32 manual has room for up to 40 bits of "address of 4KB page frame", 30 bits of "address of 2MB page frame", and 22 bits of "address of 1GB page frame". Add to those the number of bits necessary for a byte offset within the page frame, i.e. 12 bits for 4KB, 22 bits for 2MB, and 30 bits for 1GB, and you get 52 bits in all three cases, so, for Intel 64, the architectural physical address limit is 52 bits, unless they really meant to say "reserved" rather than "ignored" for the higher bits. For what it's worth, those bits are all marked as "reserved" in figure 4-7 "Formats of CR3 and Paging-Structure Entries with PAE Paging", so that could be read as implying a larger maximum physical address in legacy mode than in long mode, but I really doubt that's what they had in mind. Perhaps "ignored" means "free for software to use, as the hardware will never ever look at them", which would mean that Intel 64 imposes a hard 52-bit limit that could only be lifted by a new mode, so as not to break operating systems that stuff additional information into those bits.

For AMD, a 64-bit PTE in "long mode", according to figures 5-21 "4-Kbyte PTE—Long Mode", 5-25 "2-Mbyte PDE—Long Mode", and 5-28 "1-Gbyte PDPE—Long Mode" of Volume 2 of the AMD64 documentation, the physical page base address has the same size as it does in the Intel 64 documentation, although the bits above the physical address are marked as "available" rather than "ignored" - I don't know whether that means that they are architecturally available for use by software, which would mean that AMD64 imposes a hard 52-bit limit that could only be lifted by a new mode, so as not to break operating systems that stuff additional information into those bits.

So it appears that the 52-bit physical address is a limitation of x86-64, in both its Intel 64 and AMD64 flavors, and that AMD64 does not change that.

Unfortunately, I can't find any copies of "IA-32 Intel Architecture Software Developer's Manual Volume 3: System Programming Guide" to see whether the 36-bit limitation of Pentium Pro continued all the way with IA-32 until Intel went with x86-64, so there might have been an increase in the maximum physical address size in IA-32 beyond 2³⁶ bytes prior to the introduction of x86-64. Guy Harris (talk) 17:44, 11 October 2015 (UTC)

FYI, Windows regards bits 52 through 62 of the PTE as available for use by the OS, and uses them as a "working set list index" - a way to quickly find, in the WSL, the entry that corresponds to the physical page whose PFN is in the PTE. And of course it treats Intel64 and AMD64 the same in this regard.

In the AMD doc, page 140: "Available to Software (AVL) Bit. These bits are not interpreted by the processor and are available for use by system software." Jeh (talk) 18:23, 11 October 2015 (UTC)

Thank you very much, Guy Harris. As the Pentium Pro introduced processor feature, PAE, Physical Address(ing) Extension. The physical address in this paging schema has been expanded from 32-bit to 64-bit (bit 12 through bit 35 are actually used for addressing, bit 36 through bit 63 are reserved, bit 0 through 11 are used for paging related functions). This architecture in architectural-limit might possible point to this PAE paging schema, rather than instruction set architecture. Paging, PAE paging are both the processor-side features, they are like some an additional unit attached between processor and system memory, extending the addressing capabilities. You can also compare it with yesterday FPU located aside CPU processor, even though all of them were discussed in most instruction set architecture documents. Processors provide the mechanisms, while O/S provides the policies. NX feature is the first one to take up one of the reserved bits, as to the 52-bit architectural-limit, there is no exact route to trace. But AMD64 does not extend that architecture for physical addressing in legacy mode.

Another interpretation, in AMD64 architecture, AMD might wish to support physical memory up to 4PB, 2 to the power of 52. So it is called architectural-limit. But this physical limit is a thing of implementation rather than architecture.

Best Regards,

Aaron J. 119.53.108.56 (talk) 23:38, 11 October 2015 (UTC)

"The physical address in this paging schema has been expanded from 32-bit to 64-bit" No. The page table entries and page descriptor entries were expanded from 32 bits to 64 bits in PAE. In the 64-bit page table entry for 4K byte pages, bits 0 through 8 are used as flags, bits 9 through 11 are marked as "Avail.", which I'm guessing means "reserved for software, the hardware will never use these", bits 12 through 35 are the physical address, and bits 36 through 63 are reserved (and should be set to 0). That gives 24 bits of physical address, which, combined with 12 bits of byte offset within the page, gives 36 bits of physical address.

"This architecture in architectural-limit might possible point to this PAE paging schema, rather than instruction set architecture." The term "instruction set architecture" is used both to refer just to instruction sets (that's how ARM uses it; A32, T32, and A64 are instruction sets, and various versions of the "ARM architecture" support one or more of those instruction sets, as well as other features such as a memory management unit in some versions) and to refer to other features of the architecture as well, such as the memory management unit. In the case of x86, the "instruction set architecture" also includes the MMU.

I don't have a copy of the last IA-32-only version of Intel's documentation, so I don't know whether it also had a 36-bit limit on physical addresses, i.e. whether it required that bits 36 through 62 must be zero, and bit 63 might be required to be zero or might be the "no execute"/"execute disable" bit.

As for AMD64 and Intel 64, AMD says in Volume 2 of the AMD64 manual that, in a 64-bit PTE, bits 52 through 62 of the PTE are "reserved, MBZ" (Must Be Zero) and that, for the Physical-Page Base Address, "This is an architectural limit. A given implementation may support fewer bits.", so they appear to be saying that 52 bits of physical address is an architectural limit, although, by marking the upper bits as "reserved, MBZ" rather than "available", they might leave open the possibility of going beyond 52 bits without requiring a mode bit - I read "reserved, MBZ" as meaning that an operating system should NOT put its own data into those bits, it should set them to zero, and, in the future, on a system with more than 4 PB of main memory, with a processor doesn't ignore those bits, it could set them to non-zero values to refer to the memory beyond 4 PB. In Volume 3 of the Intel 64/IA-32 manual, however, bits 52 through 58 of the PTE are "ignored" (not "reserved, MBZ"), and bits 59 through 62 are interpreted as "the protection key of the page" if CR4.PKE is 1 and are ignored otherwise. This indicates that it'd be harder for Intel 64 to go above 4 PB of main memory, as its spec appears to promise that some of those bits are "ignored" (so that an operating system could put its own data there, and not fail if those bits are used for the page physical address in the future) and that some of them can be interpreted as the protection key of the page.

"But AMD64 does not extend that architecture for physical addressing in legacy mode." Wrong. Figure 5-12, "PAE Paging Legacy-Mode" of Volume 2 of the AMD64 manual shows bits 12 through 52 - not bits 12 through 35 - being used for the "Physical-Page Base Address".

"Paging, PAE paging are both the processor-side features, they are like some an additional unit attached between processor and system memory" But that's not what it is - x86 processors, starting with the 286, have had the MMU on the CPU chip, unlike, for example, the 68k family, where the MMU wasn't on the CPU chip until the 68030. And both Intel and AMD document the operation of the MMU in the manual for the architecture, so it's not something separate for the architecture.

"You can also compare it with yesterday FPU located aside CPU processor, even though all of them were discussed in most instruction set architecture documents." Yes, and floating point is part of the instruction set architecture as well. Guy Harris (talk) 05:34, 12 October 2015 (UTC)

Thank you very much, Guy Harris!

I go agree with you, but I have to make some explanations rather than some excuses on "Paging, PAE paging are both the processor-side features, they are like some an additional unit attached between processor and system memory." Saying that it is a processor feature rather than part of architecture, just because paging is not architecture-bound function. 32-bit linear address coming from any architecture could be paged onto 32-bit through 52-bit physical space in this schema, it is an architecture-blind feature, while segmentation is explicitly used by instruction set when addressing. But I do go agree with you.

"I read "reserved, MBZ" as meaning that an operating system should NOT put its own data into those bits, it should set them to zero, and, in the future, on a system with more than 4 PB of main memory, with a processor doesn't ignore those bits, it could set them to non-zero values to refer to the memory beyond 4 PB.", it is great and wonderful! For those architectural definitions, when in the future, system memory exceeds 4PB, all those bits should not be used for addressing, but the schema should be expanded, from 64-bit to 128-bit, similar with the segment descriptors in 80286 and 80386. The bits from bit 52 through 58 might be reserved for manufacturer specific purposes.

Best Regards,

Aaron J. 119.53.108.56 (talk) 06:01, 12 October 2015 (UTC)

The "reserved, MBZ" indication from the AMD doc is all in the "legacy mode" section 5.2. This is what would be used under a 32-bit OS. For a 64-bit OS we want section 5.3, "Long-Mode Page Translation". The PTE, etc., formats shown on page 133, 135, and 137 describe bits 52 through 62 as "available". The description of fields in section 5.4 says that that means "available to software". So, a 64-bit operating system can put its own data into those bits, just as is allowed for bits 9, 10, and 11. (I'm not disputing that writing nonzeroes to bits 52-62 would be disallowed in legacy mode. But that is irrelevant to a 64-bit OS.) As I mentioned previously, x64 Windows most definitely uses them (for a "working set list index" value).

So, yes, there is room to think that the architectural limit of 4 PB of RAM could be easily raised, without breaking existing OS code... but only for a legacy mode (32-bit) OS! For a long mode OS we are just going to be "stuck" at 4 PB without requiring OS changes. We will just all have to find ways to cope with this crippling restriction. (*grin*)

As for the "software protection key" feature described for Intel64, that appears to be quite new! It isn't in the September 2014 book, but is in the June 2015. Jeh (talk) 06:12, 12 October 2015 (UTC)

Processors are implementations of an architecture, so a "processor feature" may be specified by the architecture. Paging, as well as segmentation, are described in Volume 2 of the "AMD64 Architecture Programmer’s Manual and volume 3 of the Intel 64 and IA-32 Architectures Software Developer’s Manual. Those documents guarantee that all AMD64 processors will do paging in the fashion described in the first of those manuals and all Intel 64 and IA-32 processors will do paging in the fashion described in the second of those manuals; it's not as if each AMD64 processor or each Intel 64 or IA-32 processor gets to implement its own unique form of paging. The whole point of an architecture manual is to eliminate or, at least, minimize the amount of code that has to be changed or written new for a new processor; this includes not only user-mode code but operating system kernel code - the part of the virtual memory code that handles page tables doesn't have to be completely rewritten for each new x86 processor or System/3x0-or-z/Architecture processor, although it might need to change for new versions of some RISC processors where they chose not to put the MMU into the architecture (or even some older CISC processors like that, such as the earlier Motorola 68k processors). So, no, I don't accept any purported explanation of paging being a "processor feature" not connected with the architecture. Paging might not be visible from userland code, and even some kernel code, but there's code that has to manipulate the page tables, and either that code can be the same for all processors, if it's specified as part of the architecture as is the case in x86, or it might have to be different for different processors, if it's not specified.

And Jeh noticed that the description of the PTEs in long mode explicitly says that the bits between the NX bit and the page physical address are "available" for software use, so both AMD64 and Intel 64 will need a mode bit in order to access more than 4 PB of main memory; that limit is specified in architecture manuals, so it's part of the architecture. Guy Harris (talk) 07:04, 12 October 2015 (UTC)