1 2 Previous Next 16 Replies Latest reply on Oct 21, 2015 8:13 AM by Janagewen

    What about 64-bit IA-32 and Itanium?

      Hello, Respectful Intel,

       

      Is today's Intel 64 architecture the 64-bit version of IA-32 architecture? Or in other words, will there be any change for instruction set architecture for the further Intel processors?

       

      I need your replies badly, thank you in advance!

       

      Best Regards,

      Aaron Janagewen

       

      Message was edited by: Aaron Janagewen Remove worthless quoted words

        • 1. Re: What about 64-bit IA-32 and Itanium?
          JFFulcrum

          Is Itanium architecture dead?

          Yep.

           

          Is today's Intel 64 architecture the 64-bit version of IA-32 architecture?

           

          The -x64 changes are data amount managed by instructions, instructions  are mostly the same. Real new architecture part is a purpose-oriented instructions sets, like AVX and AES, and virtualization. Thats why our new PCs and software have little common with 90-era PCs, although many changes are hidden under the hood. I was not surprised with virtualization part in cell modem driver code.

           

          Will there be any change for instruction set architecture for the further Intel processors?

           

          The HW architecture will be more and more RISC (simpler execution blocks, in large amounts), but instruction set will be more and more CISC, thousands of instructions optimized for different tasks. I.e. you shouldnt use simple multiply instruction, you should take a broader view - for what you want to do multiply, and select best suited instructions that will do all work at once, against single large pack of data. Something like this, i think.

          • 2. Re: What about 64-bit IA-32 and Itanium?

            Hello, JFFulcrum

             

            I am so glad that you made reply to my topic, but some of viewpoints, I could not accept with, maybe only intentionally. First of all, I have to say Itanium architecture is not dead at all, because I would not believe some a transitional architecture, like x86-64 (Intel 64 or AMD64) would really take over the place of this revolutionary 64-bit architecture.

             

            As to today's Intel 64 architecture, in my own opinion, it is not the 64-bit version of IA-32. Because simply combined two similar things do not make a third one, they both what they are. Industry-Standard x86 architecture is more or less the Intel IA-32 architecture, which evolved from the 16-bit architecture introduced by 8086/8088. It has two fundamental operating modes, Real Mode and Protected Mode.  Those operating modes does not introduce different architectures, or in other words, the same architecture is operated in two different modes. In real mode, the 16/32-bit registers are operated in real style, while in protected mode 16/32-bit registers are operated in the protected style. Those different operation styles have different means(segmentation,  paging and so on) to manipulate calculations on the same architecture, brand-less word, x86. But as to x86-64 architecture, it is the product generated by extending the x86 architecture with introducing a 64-bit environment, which itself is also extended partially from x86. From the view of NT operating system, the compatibility mode is the x86 emulation engine, on the architecture level it simulates most ways of x86. All the x86 operating modes are sealed into its legacy mode, without extension or expansion, leaving only its original taste. To most of today's views, x86-64 is an instruction set extension of a x86 processor. But essentially it is not a real instruction set extension, but a standalone architecture. The real instruction set extensions such as MMX, SSE and others need fundamental architecture to provide the fundamental operating environment. So speaking of my own opinion, x86-64 is definitively not a 64-bit version of IA-32, and even not a 64-bit version of standard-industry x86 architecture.

             

            As to the real 64-bit version of IA-32 architecture, it should stay similar with IA-32, that only two fundamental operating modes, 16/32/64-bit real mode and 16/32/64-bit protected mode. This hypothetical architecture, might possibly present on future Intel 64 processors, alongside with x86-64 style, it could represent itself as the native style. And till then, Intel might possibly name that kind of Intel 64 processors as 64-bit IA-32 processors. This hypothetical 64-bit IA-32 architecture might open doors for Intel to enter consumer products. Comparing with x86-64, it is easily to implement a 32-bit operating system to execute 64-bit IA-32 applications. Because the overheads used for operating systems would be further eliminated, which in turn reduce the power consumption by the means of natural change.

             

            As to Itanium architecture, I would never believe it is gone. It is just like yesterday's VMS succeeded by NT introduced into Microsoft Windows products; and Mach succeeded heavily by XNU, introduced into OS X products. Date back to even middle of 1990s, who would believe some a day, Windows NT and UNIX would take over today's personal computing market? Applying the IA-32 codes onto the Itanium pipelines are really the challenges. Maybe similar with Windows and OS X, future Intel processors might evolve from both IA-32 and Itanium, to make a real third one. And of course, that is only my view on the things that I love most.

             

            Best Regards,

            Aaron Janagewen

            • 3. Re: What about 64-bit IA-32 and Itanium?
              JFFulcrum

              With Itanium Intel forgets, how it win the battle on desktops and entry servers: by compatibility and price. Itanium lacks compatibility, had complex environment and  was premium priced. It is not a total failure at all: IBM POWER is monstrous, incompatible with anything else and have a uber price, but IBM with every generation can show performance levels never seen before. While Itanium failed to show performance, at start even not-performance-king Sun UltraSparks was faster in many tasks. I.e Intel and HP did a new Big-RISC: huge, lavish, and with a questionable performance, especially at performance-per-watt, and a niche product finally. So shared Big-RISC fate.

               

              Intel should purchase a DEC Alpha instead of Itanium adventure: that guys was really masters of CPU architectures, and had a lowest price per MIPS.

              • 4. Re: What about 64-bit IA-32 and Itanium?

                I used AMD64 based computers for more than 10 years, and I just like it. The one who benefits mostly from x86-64 processor, I think it is Intel rather than AMD64 itself, reason is obvious that Intel does not need to put their money to persuade software and hardware manufacturers to migrate their products to their own 64-bit  IA-32 processor,  and thanks to the x86-64 processors, their IA-32 architecture would last even longer than their expectation in 1990s. Most ridiculous thing is that through the smart design of their microarchitectures, Intel 64 processors are stronger than AMD64, even seated on LGA 775 platform. Since Pentium 4, Intel does not release any revolutionary advanced microarchitecture. But AMD's Bulldozer does not realise the expectation of 2001 version of K8 microarchitecture described in Chip Architect: AMD's Next Generation Micro Processor's Architecture , which is a design from DEC for their aborted Alpha processor. AMD64 is a good thing, but for AMD, an RISC microprocessor designer, the best way to succeed is just not to be an Intel follower. Getting rid of legacy support from their AMD64 processor, and even extended into a real 64-bit processor, or even hybrid with ARM64 would be a better view of mine.

                 

                JFFulcrum, how can you say Itanium failed to "show performance", or from what kind of point? It is like the words on some a website, saying that everyone could involve in editing, but in fact, just only several minors have that right. As to DEC Alpha, it is a good architecture and processor, I know in China mainland, there are really some manufacturers producing their versions of this kind of processors. But I have no ideas about their performance and application fiels. But frankly, I dislike it, and I dislike Loongson too, not for their performance or price, just because they are not designed from the ground, just clone other's work. So I wish Intel could also release their own 64-bit version of IA-32 and never make Itanium gone!

                • 5. Re: What about 64-bit IA-32 and Itanium?

                  Respectful Intel, please allow me copy my related discussion from Wikipedia.org below, it has been largely damaged now.

                   

                   

                  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! I also wish user Jeh will not archive or blank those sections, keep it for one or two years! Thank you!
                  Best Regards,
                  Aaron J. 175.19.64.142 (talk) 07:23, 12 October 2015 (UTC)
                  I haven't archived anything on this page. Miszabot does not implement an "archive now" command. But I see no reason in keeping stale discussions around for one or two years. Perhaps the section could be hatted to reduce the clutter on the page, and denoted "closed, please do not edit" to avoid escaping archiving. Miszabot is currently set for 30 days; perhaps that is too short. Jeh (talk) 07:43, 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)

                   

                  • 6. Re: What about 64-bit IA-32 and Itanium?

                    Just because I think it a bit little mislead on the wiki article, so I made this very discussion. Where you can easily find I was also accused as pigs. They even use their policy to humiliate me! All of that is not important at all, but their articles seem a little mislead for the users, purchasers, computer science students and so on. At least I am completely exhausted, but I understand there would be few people stand on my side. I wish that I will not bark up the wrong tree.

                     

                    The append is another discussion related to this topic, where I was accused as mistaken head, quoted from Talk:Physical Address Extension - Wikipedia, the free encyclopedia. They do not give any room for other people to discuss, and busy with archiving. I have completely no ideas why they stick to Enhanced Version of PAE even harmed readers like me so easily without giving any room to hear what I said there. Frankly, I am so sure to say it is a misleading description.

                     

                    Best Regards,

                    Aaron Janagewen

                     

                    PAE is A Processor Feature

                    Physical Address Extension (PAE) is a memory management feature for the IA-32 architecture...

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

                    When AMD defined their AMD64 architecture as an extension of x86, they defined an enhanced version of PAE to be used while the processor was in 64-bit mode ("long mode").

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

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

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

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

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

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

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

                    You're just wrong.

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

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

                    This is a typical way of explanation by Jeh, this section is talking about PAE is a processor feature, and an enhanced paging schema. But all his/her words are dealing with
                    In Intel document, PAE, is also used to reference to Page Address Extension mode.

                    ,

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

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

                    Round one

                    CopperQA, you wrote

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

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

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

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

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

                    Specifically:

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

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

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

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

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

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

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

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

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

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

                    Round two

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

                    Round three

                    Legacy mode is supposed to be an exact emulation of x86
                    emulation, definitively no! No matter instructions for x86 or x86-64 are directly executed thorough microarchitecture without emulation at all for all AMD64 processors, including K8, 10h, Bulldozer or even latest ZEN! For Intel processors with EM64T Enabled, we have no ideas whether there would be emulation, but for all Intel 64 processors (Core Microarchitecture and later) there is no emulation at all! — Preceding unsigned comment added by 119.53.110.56 (talk) 14:52, 20 September 2015 (UTC)
                    Granted that "emulation" sometimes means what you're referring to.. yes, instead of emulation I should have said "is supposed to act almost exactly like x86". I hope this little discovery of my imperfect choice of words brings you much joy. However this is irrelevant to the issue of "enhanced version of PAE" phrasing. Jeh (talk) 03:21, 21 September 2015 (UTC)
                    Sorry, I comprehend English, British English and American English; but I could comprehend your English! Frankly, description on wikipedia could not be used as a referrence in some formal situations. So correct or incorrect does not really matter! So one does not need to make up for one's own words. This is the last arguement from mine on wikipedia! — Preceding unsigned comment added by 119.53.109.190 (talk) 03:30, 21 September 2015 (UTC)
                    In particular, your claim that "a real 64-bit processor does not need extending a 64-bit linear address into a 52-bit physical address" can only be described as a bizarre wording (nobody ever said anything about "extending a linear address"). Or, if you actually meant "mapping" or "translating", then you are opining in flat denial of the facts; as you are directly contradicted by this from the AMD doc, which I quoted before:...

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

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

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

                    Round four

                    a real 64-bit processor does not need extending a 64-bit linear address onto a 52-bit physical address...

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

                    There really isn't any doubt or ambiguity about it, except (apparently) in your poor, mistaken head. That you have labored for so long under this misunderstanding, spent so much time defending conclusions that had no foundation in reality... I honestly feel sorry for you.

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

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

                      how can you say Itanium failed to "show performance", or from what kind of point?

                       

                      M-m, https://www.spec.org/cpu2006/results/cpu2006.html ? Very clearly.

                      • 8. Re: What about 64-bit IA-32 and Itanium?

                        Sorry, I see nothing clear! I am talking about Itanium architecture, but what you point out is the implementations, and few information on the optimisations. So merely considering of benchmark, one could hardly make a final decision. Itanium architecture was the expected successor of HP PA-RiSC, DEC Alpha, MIPS and IA-32. It has the things which other architectures lack. I love the dark smell of  perfumes which beautiful women wear, but I do really appreciate their inner beauties. Even though I could never afford such a computer based on Itanium, but I would believe its time will eventually come.

                         

                        Best Regards,

                        Aaron Janagewen

                        • 9. Re: What about 64-bit IA-32 and Itanium?
                          JFFulcrum

                          It has the things which other architectures lack

                          Obviously, but what a price... Full software rewrite to VLIW, and again, premium priced hardware with own ecosystem. x86 software was rewritten  - to multi-threading, to SIMD ops, to 64-bit, to VT-techs - but that was a (mostly) painless process and 15 years long. Of course, with more Microsoft involvement and direct course to IA-64 Windows software rewrite could have been done quick enough, but even Apple spend 5 years for MacOS X and apps transfer from Power to x86, and Microsoft&Intel have much lower control over hardware basics.

                          • 10. Re: What about 64-bit IA-32 and Itanium?

                            Itanium is an EPIC (Explicitly Parallel Instruction set Computing) processor, as you talk about x86, which is a CISC processor, while DEC Alpha, SUN/Oracle UltraSPARC, PowerPC,  MIPS, HP PA-RiSC, ARM/ARM64 and so on are RISC processors. Transmeta Crusoe and Efficeon are VLIW processor engines. Early Itanium processors also provide a hardware-based x86 engine, which could run not only application software but also the operating systems written for IA-32 architecture. Apple does not sell some parts inside a computer, but a whole system, the processor architecture always tend to be blind for their products, they experienced transition from 68k to PowerPC, from PowerPC to IA-32, from IA-32 to the interim between IA-32 and Intel 64, and from that interim to the Intel 64. If in the future, Apple find other fortunes, they might transmit their products from Intel 64 to some unknown architecture(s). Architecture transition is comparable easier to Apple products.

                             

                            Microsoft&Intel have much lower control over hardware basics

                             

                            I have no ideas what are you talking about with this statement. Nearly almost hardware specifications have been defined by Intel, such AHCI specification, Thunderbolt, UEFI and so on. If Software programmers do not programme in Assembly Languages, then what else would they find differences between Intel 64 and ARM v7? Indeed, Microsoft products on Itanium is not a success, maybe they are not fully prepared for this new coming, or the real time is not a reach. Duplicating computing engines does really accelerate the natural change for computing, but the advanced architecture would eventually provide a really clear path for the future computing.

                             

                            Best Regards,

                            Aaron Janagewen

                            • 11. Re: What about 64-bit IA-32 and Itanium?
                              JFFulcrum

                              I have no ideas what are you talking about with this statement.

                              Intel can develop a spec, but limited in pressure to end-device manufacturers to follow it. Thats why PCI or EFI or NVMe was transfered from Intel alone to consortiums and workgroups, consisted of many vendors. Remember failed Intel attempts forcing RDRAM or BTX - they was discarded by device makers. Thunderbolt still have very little market penetration outside Apple sphere. So Itanium was boycotted and Intel had not much to deal with it.

                               

                              And about programmers. We need:

                              - firmware

                              - OS

                              - device and system drivers

                              - compilers

                              - support for that compilers in IDEs

                              - code optimizers

                              - libraries (which someone should adapt and compile)

                              - and some apps really need to consider architecture. At least Endianness can force to rewrite thousands lines of code in simple file compression utility.

                               

                              Even open-source have troubles with supporting different architectures (and ceased IA-64 and most of RISCs support last years). Commercial companies first look at market share. And Intel approach was contr-productive for market share.

                              • 12. Re: What about 64-bit IA-32 and Itanium?

                                Rambus RDRAM is excellent, at least, games written for Playstation 3 do really benefit from its high performance. Thunderbolt is really the thing differentiates Mac from most PCs. As to the Open Source Operating System, such as Linux, It is reported that when Linus working in Transmeta, he dropped the plan to support its native VLIW architecture. So from this very point, one could speculate Linux also not already well prepares for Itanium architecture. If processor side feature paging could enable O/S to implement multi-task more efficiently and conveniently on the O/S level rather than on ISA level, then the advanced features such as Speculation and Prediction introduced with Itanium Architecture could also enable future O/S to implement dynamic instruction level parallelism on the O/S level rather than on microarchitecture level. Then everything might need a refresh, and that is the only reason for most purchasers to buy a new computer.

                                 

                                Best Regards,

                                Aaron Janagewen

                                • 13. Re: What about 64-bit IA-32 and Itanium?
                                  JFFulcrum

                                  Well, VLIW architectures cursed by bad luck. We in Russia also have VLIW implementation, Elbrus, but main goverment parties lost interest to it due to slow development progress (and, mostly, because of major patents was registered in US by offshore firm and main architecture developers are also already in US). Elbrus still produced in small stocks, but military, for example, choosed OpenSPARC instead.

                                  • 14. Re: What about 64-bit IA-32 and Itanium?

                                    VLIW architectures cursed by bad luck

                                     

                                    Well, Itanium is an example of EPIC architecture, one might possibly confuse it with VLIW. As to the latter, Itanium Architecture just represents its instructions in the form of VLIW, rather than another version of VLIW. The Explicitly Parallelism is its nature, essence and the one which everything is around for this architecture, currently, implemented in the form of VLIW instruction bundle style. If in the future some new ways were found, then this Explicitly Parallelism would have changed into another face, making the familiarities with VLIW gone.

                                     

                                    Best Regards,

                                    Aaron Janagewen

                                    1 2 Previous Next