Talk:X86

Can general readers understand this article?

I think this article (and many others) needs to be tagged with a warning that it is not meant for general reading. The technical level of this and similar articles is quite high.--Polytope4d (talk) 18:15, 31 March 2017 (UTC)

I think Wikipedia has a very large number of articles that could be regarded in that way - if one handed the article to someone with utterly no specialized knowledge in the topic. It is not a requirement in Wikipedia that all articles be suitable for "general reading." The solution, assuming that there's an actual problem, is not to tag-bomb all articles that cover advanced technical topics but to improve them along the lines suggested here:

"Some topics are intrinsically complex or require much prior knowledge gained through specialized education or training. It is unreasonable to expect a comprehensive article on such subjects to be understandable to all readers. The effort should still be made to make the article as understandable to as many as possible, with particular emphasis on the lead section."

Note that the article here does have a number of WLs to other articles that explain some of the background concepts in more-accessible terms. Jeh (talk) 20:34, 31 March 2017 (UTC)

Sub-Section x86-64 fails to stat what x86-64 really is...

Extentions? What extensions?

MMX, 3DNow! and SSE, they are the instruction set extensions to the 80x86 processors, based on the architecture introduced by the 80x87 FPU, additional to the x86 instruction set. They are specific purpose instruction set extensions, they are not always necessary, they are optional, and they could not work, if without assisting with x86 (x86-64) instructions. So they are merely the instruction set extension (to the x86 instruction set).

But on the other hand, the x86-64 instruction set is quite different, it is a general purpose instruction set, it could work independently without needing assisted with x86 instructions, even though the x86-64 processor is hardwired to initialise itself onto the legacy mode, and preparation for the PAE tables is needed the assistant of x86 codes. For UEFI firmware based PC without providing the backward support for the legacy IA-32 software, it is essentially working under the pure 64-bit mode, taking most recent Linux distros and Windows Server as examples. There is another better example, that is the x86-64 based game console, PS4 and/or Xbox One. For those games consoles, there are no codes programmed in x86 or IA-32 instruction set. So again, x86-64 is not an instruction set extension, but for the natural resemblance to the x86 or IA-32 instruction set, it is a 64-bit extension of x86 architecture. The process of extending an architecture gives birth to another architecture. As to the x86-64, it is a 64-bit architecture, it is a 64-bit extended architecture of x86, it is an instruction set architecture extension of x86, it is a 64-bit variety of x86 architecture and it is x86-64. — Preceding unsigned comment added by 119.53.112.98 (talk) 09:25, 10 May 2017 (UTC)

"But on the other hand, the x86-64 instruction set is quite different, it is a general purpose instruction set, it could work independently without needing assisted with x86 instructions" That's because it includes the x86 instructions For example, the x86-64 instruction to add two numbers has the opcodes 01, 02, 03, 04, 05, 80, 81, and 83, and REX versions of some of those. The non-REX versions of those opcodes and instructions are 32-bit x86 instructions, so the add instructions in x86-64 that have 32-bit, 16-bit, and 8-bit operands are exactly the same as the add instructions in 32-bit x86 that have 32-bit, 16-bit, and 8-bit operands. So, no, x86-64 is not an instruction set that's independent of 32-bit x86. It's the result of adding 64-bit support to x86.

x86-64 should be treated the same way that 32-bit x86 is treated - just as 32-bit x86 added support for 32-bit operands and 32-bit (linear) addresses to x86, 64-bit x86, a/k/a x86-64, added support for 64-bit operands and 64-bit addresses to x86 (64-bit addresses, because it doesn't ignore the unused bits, it requires that they be all-zero or all-1, so that support for more than 52 bits of virtual address can be added in the future, without having to deal with programs that tried to stuff other information into the unused bits, as happened with the transition from System/370 to 370-XA and the transition from the Motorola 68000/68010 to the 68020). Guy Harris (talk) 17:34, 10 May 2017 (UTC)

Très bien! Your words are the precise proofs to prove that the x86-64 is an extension of the x86 architecture. Those opcode extensions (or additional opcode modifiers), such as REX, just stat that the changes have already happened to the architecture. This inclusion in your words, on the other hand, just stat the fact that the x86-64 is based on x86 architecture, extended from x86 architecture or a 64-bit variety of x86 architecture. Because even though "The non-REX versions of those opcodes and instructions are 32-bit x86 instructions", the x86 or IA-32 programmes could not run directly under the pure 64-bit mode, where this 64-bit extension really presents. This also proves that x86-64 is also an instruction set of x86-64 architecture. But that is not the "adding 64-bit support to x86", but the extending x86 to 64-bit, or 64-bit extension of x86. One could sort 16-bit instruction set found on 8086/8088/80186/80286 or real mode of following x86 and x86-64 processors, 32-bit found on x86 (IA-32) and legacy mode of x86-64 processors, and 64-bit x86-64 instruction set found on AMD64, Intel 64 and 64-bit VIA processors into a common kind, x86. But they are what they are, the architecture of x86 is x86 and the architecture of x86-64 is x86-64. — Preceding unsigned comment added by 119.53.118.201 (talk) 23:10, 10 May 2017 (UTC)

What is more, take a look at the title of chapter 2 on page 23 of http://support.amd.com/TechDocs/24593.pdf, it says "x86 and AMD64 Architecture Differences". — Preceding unsigned comment added by 119.53.118.242 (talk) 09:46, 11 May 2017 (UTC)

"adding 64-bit support to x86" is exactly the same thing as "extending x86 to 64-bit".

"even though "The non-REX versions of those opcodes and instructions are 32-bit x86 instructions", the x86 or IA-32 programmes could not run directly under the pure 64-bit mode". Yes, there's a mode bit, just as there are for at least some other 64-bit versions of instruction sets that weren't originally 64-bit, such as PowerPC/Power ISA and z/Architecture.

"the architecture of x86 is x86 and the architecture of x86-64 is x86-64." "The architecture of x86" either refers to both the 16-bit and 32-bit versions, in which case there's no good reason not to have it include the 64-bit version as well, or it refers to only one of those, in which case either the 8086, 80186, and 80286 aren't x86 (if "x86" refers only to 32-bit x86) or the 80386 and 80486 (and subsequent 32-bit x86 processors that don't have model numbers ending in "86") aren't x86 (if "x86" refers only to 16-bit x86). About the only new things in 64-bit x86 that aren't also new things in other 64-bit versions of existing non-64-bit instruction sets are additional GPRs (ARM didn't add 64-bit support to the original ARM instruction set, they added a brand new significantly different instruction set), dropping segmentation, and disallowing the single-byte encodings of INC and DEC (multi-byte encodings of the same operations are allowed). Guy Harris (talk) 10:49, 11 May 2017 (UTC)

The very first thing you ignored all the time since I first met you in 2014 is the eXtension! This is the natural difference you ignored all the time when you comparing x86-64 and x86 with other 64-bit version of other architectures. AMD emphasised it as the 64-bit extension of standard x86 architecture; Intel emphasise it as EM64T (Extended Memory 64 Technology), IA-32e, or merely Intel 64-bit extension; Microsoft emphasise it as the 64-bit extended system (Windows XP Professional for 64-bit Extended System) and x64. If it is recognised as the 64-bit version of x86, why Intel refers them two as Intel 64 and IA-32 architectures, AMD refer them two as x86 and AMD64 architecture; and Microsoft refer them as x86 and AMD64 for its internal code, and used x86 and x64 to denote those processors? The Linux source tree did really merge those two architectures into one many years ago, but it also denotes this 64-bit extension as x86-64 rather than 64-bit x86. Oracle and SUN Microsystem did really sort the x86-64 into the x86, but it also use x86_64 to denote this architecture. Sorting x86 and x86-64 into the x86 kind is used to differentiate the products based on Sun Microsystem SPARC processors, rather than saying it is the 64-bit version of x86.

This dropped segmentation is really the comprising part of x86 (IA-32) architecture, and the name x86-64 or x86_64 just imply that it is a 64-bit variety of x86 rather than the 64-bit version of x86 architecture. — Preceding unsigned comment added by 119.53.118.242 (talk) 12:25, 11 May 2017 (UTC)

On this page, Intel says

Today I’m proud to announce the Intel Itanium processor 9700 series, the seventh and final generation of the Intel Itanium product family. The 9700 series builds upon the current Intel Itanium processor 9500 series and is socket compatible with previous 9300 and 9500 series platforms, offering existing customers investment protection with improved performance and capabilities.

We make this announcement in recognition of the continued expansion of what is considered “mission critical,” and which platforms are powering these applications. With the rise of the internet and mobile, every touch point and interaction with customers, suppliers and partners became mission critical to maintain a positive experience, relationship and business. These customer-facing applications are typically built on the x86-based Intel® Xeon® processor family and software built for a scale-out environment.

Any IT transformation must take into account the increasing interdependency of these traditionally siloed mission-critical systems with new emerging mission-critical workloads running on x86 architecture. These computing environments need to converge to create an integrated, secure, flexible and agile environment. That has become possible as, over the last decade, the Intel Xeon processor family has incorporated the best innovations from the Itanium processor to offer the reliability and uptime that mission critical workloads require, along with industry-leading performance and total cost of ownership, unparalleled OEM support, and the broadest software ecosystem. Coupled with continued Intel inventions and innovations in memory, network and storage technologies, the Intel Xeon processor family will be unmatched in delivering new capabilities for mission critical deployments of the future.

which pretty clearly is talking about 64-bit processors when it's talking about x86. So Intel, at least, considers Intel 64 to be part of "x86" - and they have an incentive to do so, as they were the creators of "x86" with the 8086. AMD, on the other hand, have an incentive to distinguish the 64-bit version, as they're the creators of the 64-bit version. Note that the original name they used for it was "x86-64", and they later switched to "AMD64".

" If it is recognised as the 64-bit version of x86, why Intel refers them two as Intel 64 and IA-32 architectures" Because IA-32 is the (Intel) 32-bit version of x86, Intel 64 is the 64-bit version of x86, and they couldn't call it IA-64 because they'd already picked that name for Itanium.

"AMD refer them two as x86 and AMD64 architecture" See my earlier comment for one possible marketing reason; they want to say "x86 is that old 32-bit thing of Intel's, we're the ones who have the shiny new 64-bit thing" - which doesn't work any more, given that Intel have that same shiny new 64-bit thing, but there's no reason for them to change the brand now.

"The Linux source tree did really merge those two architectures into one many years ago, but it also denotes this 64-bit extension as x86-64 rather than 64-bit x86." Linux is a UN*X, and UN*X is the operating system where the command to list a directory is "ls" rather than "list"; "x86-64" is a shorter way of saying "64-bit x86", so they went with the shorter version. :-)

"the name x86-64 or x86_64 just imply that it is a 64-bit variety of x86 rather than the 64-bit version of x86 architecture." So how is "a 64-bit variety of x86" different from "the 64-bit version of x86 architecture"? Guy Harris (talk) 01:37, 13 May 2017 (UTC)

I have no words to that lady in Intel, put an end onto the Intel Itanium in favour of Intel x86 Xeon processor. There is nothing wrong with her words, Intel Xeon is a x86 processor since its beginning day when the world is dominated by the Intel Pentium series processors, they are the IA-32 processors, and they are the x86 processors. Intel 64 processors, or today's Xeon processors, are the x86 processors because they could support all the x86 software. The only difference is that they incorporate that 64-bit extension of x86, devised by AMD. The "x86" in her words is used to differentiate the x86 kind and EPIC kind of processors, rather than saying x86-64 is the 64-bit version of x86 processors.

64-bit version of x86 processors does stat the fact that

First, x86 is an architecture managed and developed by a company or a group who do accept each other and make an agreement with each other, from the very first day it was introduced, such as ARM, MIPS, POWER, PowerPC and so forth.

Second, 64-bit version of something does not mean that it is the 64-bit extension of something, but stats that it is some a version designed from beginning under some an agreement with all the developers. Unfortunately, Intel abandoned that 64-bit version of IA-32 decades ago, around early 90 last century. The effort AMD puts onto the x86-64 is the process of extending it onto 64-bit rather than developing a 64-bit version of something. In AMD official documents, they did and they do really emphasise the word "extension", and carefully use that word throughout all the ISA manuals. Or in other words, they do not recognised it as the 64-bit version of x86.

Third, it has a name rather than it has not a name for itself, x86-64, AMD64 and Intel 64.

Fourth, x86 architecture? AMD calls it industry-standard x86 architecture, or in other words, this name is created by the industries or organisations who use such processors and make an agreement with each other to recognise it as the x86 architecture, rather than the developers named it from the beginning.

Fifth, the x86-64 is developed outside the original major developers of x86 (IA-32), and during the development, developers from both companies do not make any agreement with each. Even though later Intel incorporate it onto their enhanced IA-32 (Intel 64) processors, they could be only counted as a 64-bit variety of x86 rather than 64-bit version of x86.

Sixth, from the viewpoints of both architectures, x86-64 is really a 64-bit variety of x86 rather than 64-bit version of x86. — Preceding unsigned comment added by 221.9.21.45 (talk) 02:13, 13 May 2017 (UTC)

"First, x86 is an architecture managed and developed by a company or a group who do accept each other and make an agreement with each other, from the very first day it was introduced, such as ARM, MIPS, POWER, PowerPC and so forth." That's completely wrong. x86 was introduced when Intel released the 8086 in the last 1970's. At least according to Advanced Micro Devices#IBM PC and the x86 architecture, AMD didn't sign a contract to second-source x86 processors until 1982, so there were a few years when there was only one company, and a company doesn't "make an agreement" with itself. In that way, it's like the POWER ISA, which was IBM-only; it wasn't until PowerPC that the AIM alliance was created, with Motorola also making PowerPC processors.

"Second, 64-bit version of something does not mean that it is the 64-bit extension of something, but stats that it is some a version designed from beginning under some an agreement with all the developers." There's nothing about "64-bit" that states that it was "designed from [the] beginning under ... an agreement with all the developers." What it means is that 1) it's 64-bit and 2) it's a version of something that wasn't 64-bit before, rather than, say, DEC Alpha, which has no "64-bit version" because there wasn't a 32-bit Alpha (PRISM doesn't count - it's similar, but it wasn't released).

"Unfortunately, Intel abandoned that 64-bit version of IA-32 decades ago, around early 90 last century.Unfortunately, Intel abandoned that 64-bit version of IA-32 decades ago, around early 90 last century." Prove it. Find a citation that Intel had a 64-bit version of x86 back then (and, no, some fanboy site speculating about it does not count).

"The effort AMD puts onto the x86-64 is the process of extending it onto 64-bit rather than developing a 64-bit version of something." You have given no evidence whatsoever to indicate that "extending something to 64-bit" is any different at all from "developing a 64-bit version of something". Just about anything that builds on an existing instruction set could be called an "extension" of it, so SPARC v9 could be considered an extension of SPARC v8, and the MIPS III R4000 64-bit version of MIPS could be considered an extension of the 32-bit MIPS II, and the 64-bit z/Architecture could be considered an extension of the 32-bit System/390, and so on. In none of those cases was a new instruction set designed from scratch; the closes thing to that is the ARM A64 instruction set, which is much more different from A32 than the other 64-bit instruction sets are from their 32-bit counterparts (dropping a heavily-used feature such as predication is more significant than dropping all of a little-used feature such as segmentation, except for enough stuff to use the segment registers as thread-local storage pointers, etc.) However, a 64-bit extension is different because it doesn't, for example, just add new instructions that use existing registers or new registers, it, in at least some cases, adds a new mode in which the existing registers are wider.

"Third, it has a name rather than it has not a name for itself, x86-64, AMD64 and Intel 64." So does z/Architecture, and so does MIPS64; SPARC just bumped the version number, and I think PowerPC had a 64-bit mode specified from the start, even if not all processors supported it.

"Fourth, x86 architecture? AMD calls it industry-standard x86 architecture, or in other words, this name is created by the industries or organisations who use such processors and make an agreement with each other to recognise it as the x86 architecture, rather than the developers named it from the beginning." It's not an "agreement", it's a convention - nobody signed some official document saying "hey, we'll call this x86", it just got called that because Intel's processor numbers ended with "86". "Industry-standard" doesn't mean the name is some standard, it just means that a lot of people are using it. ("Industry-standard" is a marketing term, not some indication that there's an Official Standard involved here.)

"Fifth, the x86-64 is developed outside the original major developers of x86 (IA-32), and during the development, developers from both companies do not make any agreement with each." So what? Again, it's not as if there's some official organization that owns "x86", and anything done outside that organization isn't "x86"; "x86" is a name used as a convention. If you think there's someone or something that official controls what's "x86" or not, and all your arguments are based on that assumption, your arguments are based on a false assumption.

"Sixth, from the viewpoints of both architectures, x86-64 is really a 64-bit variety of x86 rather than 64-bit version of x86." "Variety", definition 1.1: "a variety of" A number or range of things of the same general class that are distinct in character or quality. vs. "Version", definition 1: A particular form of something differing in certain respects from an earlier form or other forms of the same type of thing. So what exactly is the Big Significant Difference between those two words that makes "x86-64 is really a 64-bit variety of x86 rather than 64-bit version of x86." any different from "x86-64 is an X rather than an X", which is a meaningless statement? Guy Harris (talk) 03:22, 13 May 2017 (UTC)

Carefully dealing with term "x64"...

Microsoft deal with the x86-64 processors all the time as the x64 processors in no matter in their currently 32-bit or 64-bit OS. Here, one question, what does this "x64" really mean? Is it the abbreviation of x86-64? The answer might be possibly no! In late 2003, Microsoft released a beta version of Windows XP 64-bit Edition For Athlon 64 & Opteron, several months later after Windows XP 64-bit Edition, Version 2003 released. The full and exact name of that release is Windows XP 64-bit Edition for Athlon 64 & Opteron, Version 2003, yeah, a second 64-bit edition aside with the Itanium edition, but the codes were based on the beta version of Windows Server 2003 SP1 beta, two years before it released. This beta version of XP is more or less the AMD64-lised of Itanium edition, it could only work on the AMD64 processors. If trying it onto the Intel 64 processors, the installation programmes would fail to proceed. In late 2004, Microsoft released its successor, with the name, Windows XP 64-bit Edition for 64-bit Extended System. Pay attention to its name, the Athlon 64 & Opteron is replaced by the 64-bit Extended System, this is not only a name change, but also provided the support of Intel 64 processors, and its look is more or less the same as Windows XP Professional. The next year, Microsoft released its RC and official releases, they change its name again, Windows XP Professional x64, and it is its final name even until today. Comparing this name changes, 64-bit Edition for 64-bit Extended System is replaced by Professional x64. We could walk a little bit further step, divide those two clauses even further, 64-bit Edition vs Professional, and 64-bit Extended System vs x64. As its name change, it does really implies that

One, it is no more a 64-bit Edition of their current Windows system, but another Professional Edition of it.

Two, this new Professional Edition is designed for 64-bit Extended System, or x64 system.

Windows XP 64-bit Edition is different from the 64-bit version of Windows XP, such as the following releases, like Windows Vista, 7, 8 and so forth. The purpose of Windows XP 64-bit Edition is designed for 64-bit computing, applying Windows onto the then-future heavy computer field, rather than consumers or business. But the 64-bit version of Windows Vista Business Edition is just the 64-bit counterpart of it in then-current 64-bit computing world. Microsoft dropped that edition in early 2005, just before Windows XP Professional x64 was about releasing, and the latter is not its continuation, but a supplement to meet the coming 64-bit computing needs.

Most computing system incorporated x86-64 processors are not completely new 64-bit system, but something like yesterday's x86 system, only extended by those processors to possess the 64-bit computing capabilities: they initialise themselves like yesterday 8086/8088 processors, running under real mode; codes of BIOS were read started at the same entry of x86 processors; and they might stay only on the x86 OS spanning all over their lifetimes, if there is no proper 64-bit OS is provided. And that proper 64-bit OS is just that OS designed for 64-bit Extended System. Extended, pay attention to its grammatical tense, perfect, yeah, perfect. Only the x86-64 processors could extend those system to 64-bit, so those processors are also called x64 processors. In the term x64, the 64-bit extended is emphasised, and stat its unique natural differences among other 64-bit systems, such as Itanium, Alpha, UltraSPARC and so forth. So the x64 is not the abbreviated form of x86-64, it just tells the different episodes of the same story. Those systems (OSes) do not only enable those 64-bit extended system to work in the 64-bit environment, but also extend previous already mature 32-bit programmes to work on the 64-bit environment too, in favour of the advanced system mechanism, gaining the performance improved. Besides Microsoft, SUN MicroSystem also released their x64 OS, Solaris 10, they also provided the best support of legacy 32-bit software, when providing the 64-bit support. The backward support for the legacy x86 applications is not an optional part for x64 OS; but an optional part for x86-64 OS, such as Linux and FreeBSD. — Preceding unsigned comment added by 119.53.116.64 (talk) 05:43, 14 May 2017 (UTC)

"Microsoft deal with the x86-64 processors all the time as the x64 processors" Microsoft calls the 64-bit version of x86 "x86". Other OS vendors call it "x86-64",or "amd64".

"what does this "x64" really mean? Is it the abbreviation of x86-64? The answer" The answer is "it's another way of referring to 64-bit x86", just as x86-64 is.

"Microsoft released a beta version of Windows XP 64-bit Edition For Athlon 64 & Opteron, several months later after Windows XP 64-bit Edition, Version 2003 released." Yes, they first released a 64-bit version of Windows for IA-64/Itanium, then they released a 64-bit version for 64-bit x86.

Seriously, you seem to be obsessed with the notion that minor name changes mean something deeply significant. THEY DON'T. I won't waste any time taking your personal believe about what "extended" signifies, or "x64" signifies, or "version" signifies, or... seriously, so don't waste your time, or ours, talking about it. Trust me, I've worked as a developer of system software for decades, at companies such as Sun, NetApp, and Apple; I've seen the computing field from the inside, so I know that OS names are cooked up by marking departments, just as the word "industry-standard" are, and don't necessarily reflect anything technically significant.

"In the term x64, the 64-bit extended is emphasised, and stat its unique natural differences among other 64-bit systems, such as Itanium, Alpha, UltraSPARC and so forth." Its different from other 64-bit systems is that it's x86 rather than something else. Like SPARC, and like MIPS and POWER/PowerPC and PA-RISC and z/Architecture, but unlike Itanium and Alpha, the 64-bit version was preceded by a 32-bit version (32-bit x86 -> 64-bit x86, SPARC v7/v8 -> SPARC v9, some of the implementations of which are called "UltraSPARC" - others are called, for example, "SPARC64", MIPS I/MIPS II -> MIPS III, 32-bit PowerPC -> 64-bit PowerPC, PA-RISC 1.x -> PA-RISC 2.0, System/390 -> z/Architecture). Unlike SPARC and the others, the 32-bit version was preceded by a 16-bit version. (ARM is a bit different, in that A64 is not just "A32 extended to 32-bits".)

"Those systems (OSes) do not only enable those 64-bit extended system to work in the 64-bit environment, but also extend previous already mature 32-bit programmes to work on the 64-bit environment too," Yes, all the 64-bit architectures that were preceded by a 32-bit version can, in hardware, support both 32-bit and 64-bit code running on the same OS, if the OS supports it, and the OSes for them largely do support running 32-bit applications and 64-bit applications at the same time on a 64-bit OS (Windows, Solaris, HP-UX, AIX, *BSD, macOS, iOS and most if not all Linux ports do - I think the PA-RISC port may be a bit weird in that regard). x86 is not anything special here.

"The backward support for the legacy x86 applications is not an optional part for x64 OS; but an optional part for x86-64 OS, such as Linux and FreeBSD." Again, you are making the mistake of thinking that "x64" and "x86-64" mean something significantly different. THEY DON'T. Backward support for 32-bit applications is not optional if you have a large base of 32-bit applications, regardless of whether you call the 64-bit x86 "x64" or "x86-64" or "AMD64" or "Roland The Headless Thompson Gunner". Windows obviously has a big base of 32-bit applications, source to which isn't available to users so they can't recompile it, so they had to support WoW64 - that's not a technical issue, that's a marketplace issue. Apple had the same issue with macOS. It's also not an issue unique to x86; Solaris had binary third-party 32-bit SPARC applications for Solaris, so they had to support 32-bit SPARC code on their 64-bit Solaris systems, HP had binary third-party 32-bit PA-RISC applications for HP-UX, so they had to support 32-bit PA-RISC code on their 64-bit HP-UX systems, IBM had binary third-party 32-bit PowerPC applications for AIX, so they had to support 32-bit PowerPC applications on their 64-bit AIX systems; IBM also had binary third-party System/390 applications for OS/390 (and MVS for System/370 ESA and System/370-XA and even System/370 with 24-bit addressing - heck, there may still have been some OS/360 binaries!), so they had to support (32-bit) System/390 applications on their 64-bit z/Architecture z/OS systems. Oh, and Apple had binary 32-bit ARM applications for iOS, so they had to support 32-bit ARM code (A32 or T32) on their 64-bit iOS systems.

The only thing that makes it potentially optional for Linux and *BSD is that there are a lot of free-software applications that can be recompiled by the user or by the packager of the distribution or that can be distributed in source form (see Gentoo and the "port collections" in at least some *BSDs). It has nothing to do with the name they give to 64-bit x86. Guy Harris (talk) 09:27, 14 May 2017 (UTC)

x64 is a special thing, and a special term like what I explained above, because can you put a 64-bit processor other than x64 onto a 32-bit system directly or only with firmware updated? Term x64 is not only another way to refer to the thing which x86-64 refers to, but also promise that it could be a 32-bit processor it extends, before extending a thing, it should become that thing! And that is unique meaning of term x64, which Microsoft used and use, all the time. — Preceding unsigned comment added by 119.53.117.95 (talk) 23:46, 14 May 2017 (UTC)

x86 is an architecture rather than architectures...

In AMD official documents, it is referred as industry-standard x86 architecture; in Intel documents, this architecture is referred as IA-32 architecture. In most occasions, x86 is used to refer to a 32-bit architecture, more or less, the IA-32; but it is also used to refer to those processors which incorporate x86 architecture and its varieties. In history many processor manufacturers did really bring up so many processors based on x86 architecture, but the software for them are incompatible with processors from Intel and AMD. But they are all sorted onto the x86 class. Because x86-64 architecture includes the x86 architecture within its legacy mode, such processors could run x86 software, so this architecture could also be sorted into x86 class. x86 has at least two layers of meaning:

One, x86 is the architecture of 32-bit Intel processors and their clones from AMD, Cyrix, IDE, NS, Rise, VIA and so forth. Those clones brought up the their instruction set extensions to IA-32 architecture, such as 3DNow!, MMX+ and so forth. Those are the instruction set extensions, they do not change the architecture of x86 (IA-32).

Two, a class of processors and their associated architectures.

x86-64 architecture is the product of extending the x86 architecture, and includes the unmodified x86 architecture in its legacy mode. It is quite like in the object-oriented programming, the x86 is the base class, and the x86-64 is the derived class, and includes the object instanced from class x86 as its attribute or property (legacy mode) in the form of union rather than structure. Each processor might be instanced from x86 or x86-64 class. Because the class x86-64 is derived from x86, so the processors instanced from x86-64 would have everything which processors instanced from x86. So they could be sorted into the same class, x86. To a further step, in this union form, when its attribute (legacy mode) is referenced, it acts almost as a real x86 processor. But in the opposite direction, x86 processor is not an x86-64 processor, because it lacks of the extended attributes (architectural extensions) and operations (extended instructions), which belongs to class x86-64 natively. The relationship of x86 and x86-64 is the being extended (derived), rather than modifications. Only the modifications are put onto the base class, x86, the result would bring out another version. So x86-64 is not some a version of x86, and not its 64-bit version.

In Intel documents, 16-bit processors like 8086/8088, 80186/80188 and 80286 are treated as the previous or early IA-32 processors, the architecture they possess eventually evolved into the final IA-32 architecture. So x86 is an architecture, rather than many architectures or many versions of a specific architecture. — Preceding unsigned comment added by 119.53.116.64 (talk) 11:30, 14 May 2017 (UTC)

"In AMD official documents, it is referred as industry-standard x86 architecture" As I already said, that's probably because AMD wanted to promote AMD64 as being based on an "industry-standard architecture" (a marketing term, not a technical term), unlike IA-64. That has no deep significance.

"In most occasions, x86 is used to refer to a 32-bit architecture," [citation needed]

"In Intel documents, 16-bit processors like 8086/8088, 80186/80188 and 80286 are treated as the previous or early IA-32 processors" Somebody needs to ask the person who wrote that what "32" in "IA-32" means.

This is all your personal interpretation of what terms mean. I have seen nothing whatsoever to indicate that your personal interpretation is anything other than a personal obsession. Guy Harris (talk) 17:04, 14 May 2017 (UTC)

"In most occasions, x86 is used to refer to a 32-bit architecture," [citation needed]

https://msdn.microsoft.com/en-gb/library/windows/hardware/ff561499(v=vs.85).aspx

http://www.pcmag.com/encyclopedia/term/54979/x86

Two occasions is not "most"- and the second occasion actually doesn't say that. The PC Magazine article says:

(1) x86 generally refers to definition #2 below; however, the term may also be used to differentiate 32-bit hardware and software from their 64-bit counterparts in Windows PCs (see x64).. See Program Files x86.

(2) The world's predominant personal computer CPU platform. Used in Windows and Linux PCs, Macs and Chromebooks, the x86 line was developed by Intel and includes the Core, Xeon, Pentium, Atom and earlier 286, 386 and 486 models (hence, the "86").

Most Intel "Core" processors are 64-bit; the only ones that weren't were the original Core processors. Core 2, and everything after it, is 64-bit.

It then goes on to say

AMD is also a manufacturer of x86 CPUs with brands such as Athlon, Sempron and Opteron.

and Opteron are definitely 64-bit.

The table in that article lists 16-bit, 32-bit, and 64-bit processors under "x86 processors (from Intel)".

So you've found only one place where x86 never includes 64-bit - Microsoft's terminology - and one place where it primarily does include 64-bit, with a side note that, in Windows PCs, it's used to refer to 32-bit, so that basically just says "Microsoft uses it to refer only to non-64-bit, but it usually includes 64-bit".

I.e. so far, there's only one occasion, namely Microsoft's terminology. Guy Harris (talk) 01:07, 15 May 2017 (UTC)

x86 architecture and x86 class have been emphasised above. They are two things. x86 is an architecture, more or less the IA-32. x86-64 is a 64-bit architecture extended from x86 architecture, and incorporate it entirely. As to this extension, I have explained it carefully with the analogue with things in object-oriented programming. The x86-64 architecture is not a revolutionary product like EPIC architecture, but the process from the x86 to the x86-64 is revolutionary, so it is not some a version of x86, not part of x86, but just a 64-bit extension of it rather than to it! In the viewpoint of this wiki article, the major author(s) just confuses this extension with versions of the same or similar things.

If one would prefer to saying that the 32-bit architecture introduced by the 80386 is the extension of the 16-bit architecture found on those 16-bit x86 processors, he or she would recognise they are two architectures. But in fact, it is one architecture, but only at different phases. The architecture in real mode, 16-bit protected mode and 32-bit protected mode is the same one in IA-32 or x86 processors, only working in different modes (methods). The values in those registers are consistent within each different mode. But the values in those registers are inconsistent in legacy mode and long mode, that is to say, it is not only a different operating mode, but also a different architecture, even if similar. In this way, x86 is one architecture again! It is not a family of several similar or related architectures. The only relationship between x86 and x86-64 is the latter is born after extending the former from levels. And this very relationship makes users, developers, manufacturers refer those two kinds of processors as the x86 processors, without any word saying that "Oh, you see, the architecture of Core i7 is the 64-bit version of x86." They would love to say that "The x86 processor, Core i7 is an Intel 64 processor, the architecture of it is Intel 64 architecture. And this Intel 64 architecture is similar with AMD64, could be called x86-64!"

The confusions lie on those things are not problems of languages, English or American; but the different things, and false recognitions. 221.9.17.75 (talk) 02:51, 15 May 2017 (UTC)

"x86 architecture and x86 class have been emphasised above." Your personal belief about them was emphasized by you above. I don't think you have a clue what you're talking about, so I'm not going to simply accept your assertions.

"They are two things. x86 is an architecture, more or less the IA-32. x86-64 is a 64-bit architecture extended from x86 architecture, and incorporate it entirely." I disagree, because you have not presented anything that resembles solid evidence, based on a solid understanding of computer instruction sets; you have just presented a bunch of assertions. I do not accept those assertions, and will not accept them without providing something that I consider to be solid logic backed by solid evidence. Guy Harris (talk) 07:35, 15 May 2017 (UTC)

"As to this extension, I have explained it carefully" No, you've just made a bunch of assertions...

"But the values in those registers are inconsistent in legacy mode and long mode" The values of the first 8 general purpose registers are as consistent between 64-bit mode and 32-bit mode as they are between 32-bit mode and 16-bit mode.

"with the analogue with things in object-oriented programming." You haven't even mentioned object oriented programming.

"If one would prefer to saying that the 32-bit architecture introduced by the 80386 is the extension of the 16-bit architecture found on those 16-bit x86 processors, he or she would recognise they are two architectures." What is the difference between an extension to an architecture and a separate architecture?

"The x86-64 architecture is not a revolutionary product like EPIC architecture" True.

"but the process from the x86 to the x86-64 is revolutionary," What's "revolutionary" about it, other than "nobody else thought of stretching x86 to 64 bits"?

"In the viewpoint of this wiki article, the major author(s) just confuses this extension with versions of the same or similar things." Somebody's confused; unfortunately, that "somebody" is you.

Look. You are trying to convince a person who has been a software engineer for more than 40 years, writing kernel-level operating system code. If you think you're an expert trying to educate a novice, you are strongly advised to completely abandon that notion. (And, by the way, you might be spending your time arguing with more than one person with that at least level of experience and knowledge....) Repeating your assertions over and over again is not going to convince me. If you're also a software developer who's worked at that level, you can probably come up with arguments based on more than just arguments about the meaning of words; if you're just a fanboy who's read a bunch of articles and thinks that makes him an expert who can lecture people with more experience in the field, you're simply wasting your time and convincing us that you're a fool.

(And, no, randomly tossing in a reference to Francis Bacon is far from sufficient to convince me you're a Deep Thinker rather than somebody who's followed William Claude Dukenfield's dictum.) Guy Harris (talk) 07:35, 15 May 2017 (UTC)

Careful, Guy. Any moment now, Janey from China will start accusing you of "misleading". Jeh (talk) 08:36, 15 May 2017 (UTC)

"Repeating your assertions over and over again is not going to convince me. If you're also a software developer who's worked at that level, you can probably come up with arguments based on more than just arguments about the meaning of words; if you're just a fanboy who's read a bunch of articles and thinks that makes him an expert who can lecture people with more experience in the field, you're simply wasting your time and convincing us that you're a fool."

Software developers, no matter at which level, are applying the codes provided by architecture(s) to specific applications. Their works consolidate the success of that or those architecture(s), such as x86 architecture. There are many and many more software averaged almost in every field programmed in x86 architecture. So this architecture is emphasised, the architects only extended it rather than modify it. Without considering around too many legacies, the Linux developers would consider few about the backward compatibilities. So the yesterday's stale and compiled software almost find no way to work on today's Linux distro directly. That draws the different views and sights among different developers even if they work on the same architecture. Software developers even though make good use of the resources provided by architecture, and contribute too a lot to make it mature, but they go a completely different way from architects, who research, develop and even devise or evolve the new architectures. The work to develop a system kernel is different from the work to design a system kernel. Even though the driver programmers know more a lot around the internals, but they have few knowledge about why the kernel designers do something like that, stupid or smart. The system designer might not want to devote energy towards the details, but they understand what they did are what they like. I found something on this wiki article incorrect, so I talked about them on the talk page, and that is it! — Preceding unsigned comment added by 221.9.19.232 (talk) 13:49, 15 May 2017 (UTC)

You found something you didn't personally agree with, and kept talking about it. At least one of the citations you gave to support your belief turned out to disagree with you!

The rest of your comment above is just a word salad meaning nothing. Sorry, I just don't take you seriously as an expert on x86, or any other computing topic, and won't do so until I see signs of clear thinking on your part. Guy Harris (talk) 18:36, 15 May 2017 (UTC)

Ridiculous! Do you remember the sentence "only release to support x86"? What such a big mistake you made when a so-called native English speaker and expert for programming more than 40 years? Seriously ridiculous! Your words build up the pictures in your reach (capabilities), so readers from all over the world would know your actual extents. Sorry, this wiki article is the product of many contributors, and my words left here is not for any single one... — Preceding unsigned comment added by 221.9.17.174 (talk) 22:15, 15 May 2017 (UTC)

Merger proposal

• X86 (edit | talk | history | protect | delete | links | watch | logs | views)
• X87 (edit | talk | history | protect | delete | links | watch | logs | views)
• Intel 8086 (edit | talk | history | protect | delete | links | watch | logs | views)
• Intel 8088 (edit | talk | history | protect | delete | links | watch | logs | views)
• Intel 80186 (edit | talk | history | protect | delete | links | watch | logs | views)
• Intel 80188 (edit | talk | history | protect | delete | links | watch | logs | views)
• Intel 80286 (edit | talk | history | protect | delete | links | watch | logs | views)
• Intel 80386 (edit | talk | history | protect | delete | links | watch | logs | views)
• Intel 80486 (edit | talk | history | protect | delete | links | watch | logs | views)
• IA-32 (edit | talk | history | protect | delete | links | watch | logs | views)
• X86-64 (edit | talk | history | protect | delete | links | watch | logs | views)
• IA-64 (edit | talk | history | protect | delete | links | watch | logs | views)

There has been a suggestion that IA-32 might be merged into this article. Now, while it appears that the suggestion may have been from someone evading a block, it seems worthwhile opening a merger discussion for comments from users in good standing. As far as I can see, there has not been a recent formal discussion of a possible merger. What do people think of the idea? In particular, why should we keep a separate IA-32 article?

 Note: comments from sock puppets may be struck, hidden, or removed. Please don't do it.

Murph9000 (talk) 23:21, 17 May 2017 (UTC)

• As proposer, I'd also like to specifically open the door to alternatives to this merge, such as splitting out content from this article which is specific to IA-32, merging that into the IA-32 article instead. Right now, x86 is a large article, and IA-32 is a quite small article, do we have the appropriate balance? Murph9000 (talk) 23:42, 17 May 2017 (UTC)
•  Note: for convenience and context, I've added article links to the top for much of the extended family and related, which have appeared in the ongoing discussion. Murph9000 (talk) 10:50, 19 May 2017 (UTC)
• Oppose per WP:SIZERULE. x86 is already too large. It cannot accommodate this article with all its details. FleetCommand (Speak your mind!) 23:57, 17 May 2017 (UTC)

  @FleetCommand: Ok, so do you see any scope for splitting content from this article into IA-32 instead? Murph9000 (talk) 23:59, 17 May 2017 (UTC)

  As a matter of fact, I do. Sections "32-bit" and "Protected mode". The latter is already a summary-style section, so even content duplication would do, although I'd do some adjustments. FleetCommand (Speak your mind!) 00:06, 18 May 2017 (UTC)

• Theoretically, the x86 article should be the 8086 and all its decendants, while IA32 is only the 32 bit extension. Even more, the x86-64 article should only be the 64 bit extensions to IA32. I suspect that too many people say (and link to) x86 when they mean IA32. Gah4 (talk) 00:27, 18 May 2017 (UTC)
• Thinking about this more, x86 could be a disambiguation page to 8086 (including 8088), 80186, and 80286 pages. Then the IA32 page for the 386 up to, but not including, the 64 bit architecture. Where reasonable, don't discuss items from previous processors, but reference the appropriate page. Gah4 (talk) 00:27, 18 May 2017 (UTC)
  • "x86" is widely used in the industry to cover processors all the way from the 8086 through the latest Cores and Ryzens; making it a dab page for only the 16-bit x86 processors would be misleading. Guy Harris (talk) 00:46, 18 May 2017 (UTC)
    • I didn't mean only those, but the later ones are described by the appropriately named architecture, instead of individual processors. But links to the processors would also be fine. Gah4 (talk) 01:27, 18 May 2017 (UTC)
      • I.e., you meant "x86 could be a disambiguation page to 8086 (including 8088), 80186, and 80286 pages, and the IA32 page for the 386 up to, but not including, the 64 bit architecture"? The first sentence was followed by a sentence fragment, so it wasn't quite clear. If so, what should be done about x86-64? Link to that as well?

• If we had a "16-bit x86" page, discussing the versions of the x86 ISA in the 8086/8088, 80186/80188, and 80286, we'd then have pages for all three variants. The "Addressing modes" section could then be carved up and put into "16-bit x86", IA-32, and x86-64; the same could be done for the "16-bit", "32-bit", and "64-bit" sections of "x86 registers". The "Structure" section could also show the 16-bit, 32-bit, and 64-bit structures.

But that might involve duplication of information in ways that don't fully show the continuity between the three versions of the ISA. Guy Harris (talk) 01:03, 18 May 2017 (UTC)

I think showing the continuity is important. Jeh (talk) 05:12, 18 May 2017 (UTC)

• I still vote for x86 as a disambiguation page. After that, I am somewhat open to what goes where. Some compromise between excessive duplication and not enough continuity. It looks to me like 8086 and 8088 do a fine job of balancing the two, with the latter mostly about the differences, and reasons behind them. Well, maybe slightly more than the usual disambiguation. It could have a little on the generalities of 16 bit, 32 bit, and 64 bit intel processor series', with the details going into linked pages. Date ranges, and the reasons behind going to the next series would seem about right. Note also that with each generation, a large fraction of users used it just as a faster version of the previous system, and not actually using the added features. Gah4 (talk) 14:31, 18 May 2017 (UTC)

I see no justification whatever for changing x86 to be a disambiguation page. It's not just an industry-standard term, it's the industry-standard term for this series of architectures and the processors that implement them. Specific implementations like 8086 but there is no need to have a DA page over them - the table here does a good job and provides far more info for selecting among them than a DA page is allowed to have. (There are limits on the format and content of DA pages.) Jeh (talk) 15:15, 18 May 2017 (UTC)

Hmmm. There are lots of references to x86 inside intel.com, but mostly in forums, written by non-intel people. Some people do use x86 as a synonym for IA-32, but it should really be used for the whole series of processors, 8086 and its descendants. But OK, not exactly a disambiguation page, but with enough detail to separate the different processors and architectures, leaving the details to the individual pages. So, maybe one paragraph each for 8086 through 80286, linking to its page. Then a longer description of IA-32, as an architecture, with a link to its page, along with smaller descriptions of the processors implementing it with links. And then the history (from AMD64 to EM64T, Intel64 and x64) of 64 bit processors. Maybe also a description of IA-64, and where it belongs in the series. Do note that Windows 10 won't run on an 8086, no matter what you call it. Most 32 bit Windows systems will run 16 bit (MS-DOS days) code, but later 64 bit versions of Windows won't. More than the usual disambiguation, enough details to direct people to the appropriate page, and some history of what came when, and why. Actual details such as register names and opcodes should go on the linked pages. Gah4 (talk) 16:26, 18 May 2017 (UTC)

To be more specific, about the first third of the page seems about right. After that, it is too detailed by about a factor of 2 or 3. Details about register bits and such could go on other pages. Gah4 (talk) 16:48, 18 May 2017 (UTC)

I see no advantage in that. Anyway, that is off-topic from the question of whether to merge IA-32 to here. You're talking about a major reorg of this page, including splitting it up into multiple other articles. I can't see how moving e.g. the register names and opcodes out of this page impinges on that question. Jeh (talk) 12:46, 19 May 2017 (UTC)

Recent disruptive editing

Hey guys.

I was wondering if anyone could fill me in on this round of forth and back reverts. Specifically, what's wrong with it? The red link problem I understand. But the colors? And the generation column? By the way, why isn't there a "generation" column. I remember there was one before.

Thanks in advance, guys.

FleetCommand (Speak your mind!) 12:38, 10 June 2017 (UTC)

First, the IP is clearly an SP of long-indef-blocked LTA Janagewen and is simply not permitted to edit. See here.

The "generations" column always was always largely unsourced. Janey once admitted as such in an edit comment, noting that he'd simply assigned various processor models to certain "generations" based on his own whim. There are no references I've been able to find for any notion of "generation" numbers that are common to and agreed upon by multiple manufacturers, not for more recent series anyway. Accordingly I removed the column with this edit. This was further discussed here on the talk page - it's now in the 2017 archive. There is consensus for a table without the "generations" column, a "Chronology" table sequenced by year. Janagewen continues to try to edit-war his own version of the table into the article, which version now includes many other changes, also undiscussed, unreferenced, and supported only by Janagewen's views of the industry, which are unique to say the least; see for example this. I recommend WP:RBI. Jeh (talk) 13:25, 10 June 2017 (UTC)

@Jeh: I see. It think I am familiar with Janagewen. But I didn't know the generation column was OR because I kept running into generation numbers in various articles, e.g., "The Athlon 64 is an eighth-generation, AMD64-architecture microprocessor produced by AMD". Or Intel, which keeps saying things like "2nd-Generation Intel Core i5". I didn't know there is no global pattern. FleetCommand (Speak your mind!) 06:52, 14 June 2017 (UTC)

It appears that from sources like industry trade journals there was general agreement on "generation numbers" through about the 7th - AMD's K7 achieving near feature parity with Intel's "seventh" gen. But with AMD haring off to do x64 while Intel made only an "8th generation" 32-bit CPU, it was no longer possible to say "this one is like that one, because they're both of the same generation". Which made the column not only unsourced, but uninformative. I suppose we could restore it if we qualified the gen. number, for 8th gen and later, by manufacturer, but again, good sources would have to be found. Yes, it is possible to source statements like "2nd-Generation Intel Core i5". But it is not, as far as I can tell, possible to relate that to a series of non-product-line-specific gen. numbers. Certainly we are well beyond the "2nd generation" in the x86/x64 world! In the meantime, ordering the table by introduction date seems sufficient. And even if we do find a way to include a well-sourced "generation" column I would argue that the table should not be sorted thereby, since at this point they're basically marketing names. Jeh (talk) 07:05, 14 June 2017 (UTC)

Such similar words from Jeh had been repeated for times since 2015, but he did nothing at all to improve that table! I just wish such someone like this goes away, you are not belonging here essentially! — Preceding unsigned comment added by 175.19.66.130 (talk) 10:32, 18 June 2017 (UTC)