Talk:X86/Archives/2017

'32-bit x86' and '64-bit x86'

One thing that confuses me (and others users of what I can see in discussions and also the industry as a whole, because of the lack of standards) is the naming conventions for the 32-bit and 64-bit versions of x86, which is currently titled IA-32 and x86-64 here on Wikipedia.

Instead of mixing the instruction set architectures with the bit size in the names and using cryptic abbreviations that are not understood by non-tech people, I think it would be better to use two words for each and just call them what they are - 32-bit x86 and 64-bit x86. That would easily distinguish them from each other and from other types (like 32-bit ARM).

As I read Intel's own definition of IA-32 Architecture, it refers to systems based on x86 processors (32-bit or 64-bit processor) running a 32-bit operating system. And Intel 64 Architecture is when both CPU and OS is 64-bit.

x86-64 is just a commonly used name, not an industry standard, and other variants are used as much or even more. The description here on Wikipedia, "64-bit version of the x86 instruction set", like the 32-bit version also is described, could just be shortened to 64-bit x86. These shorter names are also used different places already in the articles.

So my suggestion is to call and rename these two versions of the x86 instruction set to 32-bit x86 and 64-bit x86, the make is easier to read and understand.

/PatrikN (talk) 04:10, 8 November 2016 (UTC)

x86-64 is a sufficiently commonly used term that I suspect more people 1) would search for it rather than for "64-bit x86" and 2) would recognize it more easily than "64-bit x86".

IA-32 isn't so common, but that's probably because 1) Intel only invented it as a contrast to IA-64, whose only commonalities with IA-32 were a) they had similar name syntaxes both mentioning Intel and b) IA-64 processors had a slow mode for running IA-32 programs; people are probably more likely to think of it as "i386" or "i686", even though the 80386 and Pentium II have long since ceased to be sold or used.

The document you cite quite explicitly says "IA-32 Architecture refers to systems based on 32-bit processors"; there's nothing about 64-bit processors. They later say "If the system is running a 32-bit version of the Windows operating system, then IA-32 architecture applies instead.", but that really means "it's an Intel64 (i.e., x86-64, Intel variant) processor, but we're only using the IA-32 part of Intel64". Equivalents would be "If the {SPARC V9, 64-bit MIPS, z/Architecture, 64-bit PowerPC/Power ISA, ARMv8-A} system is running a 32-bit operating system, then the {SPARC V8, 32-bit MIPS, ESA/390, 32-bit PowerPC, A32/T32} architecture applies instead". I.e., the OS limits what capabilities of the processors are actually available to code running on the OS; the underlying hardware is still 64-bit, and thus {x86-64, SPARC V9, 64-bit MIPS, z/Architecture, 64-bit PowerPC, A64/A32/T32}-capable, but you can't actually treat it as such when running a 32-bit OS. Guy Harris (talk) 04:27, 8 November 2016 (UTC)

Like you say, IA-32 isn't so common, actually I can't find almost anything when searching the net, apart from Intel documentation and references to low level programming. When I search for "32-bit x86" download I get what I expect, namely links to software downloads for 32-bit x86 systems. This is also the only thing I see when downloading software. I can't remember I have ever seen IA-32. Therefore I still think this is a better/more common use for this "combination", since this is the information people are looking for/need to know.

For 64-bit it's a bit more tricky, since different variants are commonly used. The reason I would prefer a combination of x86 and 64-bit (e.g. 64-bit x86, but it can also be a longer name or a variant of it), instead of "abbreviations" like x86-64 or just x64, is because it better describes what it is, I think, and also conforms to 32-bit x86.

In the same way, the articles about ARM and SPARC for example, uses 32-bit ARM and 64-bit SPARC, and therefore it would be logical to use the same terminology here, and 32-bit x86 is already used on several pages (91).

/PatrikN (talk) 01:17, 9 November 2016 (UTC)

References

The "Chronology" table

I have preserved the old chronology table (with the "generations" column) in the HAT below, for ease of reference.

In changing it to its present form I:

• Removed the "generations" column, which was completely invented by Wikipedia editors. There is no reliable source for a "generation number" that applies across all of the manufacturers. It may be possible to reference manufacturer-specific "generations" but these seem to me to be more a matter of the mfrs' marketing departments' whims than aids to understanding.
• Removed all of the remaining "rowspan" attributes, because they made reordering the table difficult. These could probably be restored (for the "bits" columns) but since more reorg may happen, now would likely be premature.
• Re-ordered the table in chronological order.
• Made these minor corrections of fact. These are the only changes of factual detail I have made, so accusations that the table now has "lots of wrong data" are clearly unfounded.

Jeh (talk) 03:48, 12 October 2016 (UTC)

Suggestions for future work (other than adding references for all existing claims of fact, which is really really important):

• I'm still not comfortable with the "segment bits" info. This column now indicates the number of bits in a segment index, i.e. the number of entries in the segment descriptor array. Some notes need to be added here like "segmenting does not apply in long mode" (but for those procs, segmenting does apply in legacy mode, and so the "segment bits" are still relevant)
• Should there be columns for max supported clock speed? Max cache size? Max number of cores? Feature size? ...
• It would be nice to be able to show how features introduced in one line are carried, or are not carried, through to following lines. But, a simple implementation would require a massively wide table with a check-box column for each feature. It would get messier if there were cases where not every member of a product family (i.e. one line on the chart) implemented all of the features.

Jeh (talk) 19:53, 12 October 2016 (UTC)

Is this turning into List of x86 microprocessors? Guy Harris (talk) 20:16, 12 October 2016 (UTC)

I think it's a supposed to be a "list of significant x86 developments". We certainly don't need to include every model number described by each row. I hate "list" articles in general because they provide no information to put the list items into context, show how they relate to each other, etc. Put it this way - if an article requires no RSs beyond somebody's product or parts catalog, it's not an encyclopedia article. Jeh (talk) 20:29, 12 October 2016 (UTC)

The previous major version of the "chronology" table (prior to removal the "Generation" column, which was pure WP:OR) is preserved here for reference. Please do not modify it. Click the "Show" link at the right end of this box to view it. Jeh (talk) 13:53, 19 October 2016 (UTC)
The following discussion has been closed. Please do not modify it.
Generation First introduced Prominent consumer CPU brands Linear/physical address space Notable (new) features 1st 1978 Intel 8086, Intel 8088 and clones 16-bit / 20-bit First x86 microprocessors 1982 Intel 80186, Intel 80188 and clones, NEC V20/V30 Hardware for fast address calculations, fast multiplication and division 2nd Intel 80286 and clones 16-bit ((14+16)-bit segmented) / 24-bit MMU, for protected mode and a larger address space 3rd (IA-32) 1985 Intel 80386 and clones, AMD Am386 32-bit ((14+32)-bit segmented) / 32-bit 32-bit instruction set, MMU with paging, PGA132 socket 3rd/4th 1992 Cyrix Cx486SLC, Cyrix Cx486DLC L1 cache and pipelining introduced into the 386 platform, PGA132 socket 4th (FPU) 1989 Intel 80486 and clones, AMD Am486 RISC-like pipelining, integrated x87 FPU (80-bit), on-chip cache, PGA168 socket 4th/5th 1997 Am5x86, Cyrix 5x86, Pentium OverDrive Partial Pentium's specification brought into the 486 platform 5th (Superscalar) 1993 Pentium, Pentium MMX, Rise mP6 Superscalar 64-bit databus, faster FPU, MMX (2× 32-bit), Socket 7 5th/6th 1996 AMD K5, Cyrix 6x86, Cyrix MII, Nx586 (1994), IDT/Centaur-C6, Cyrix III-Samuel (2000), VIA C3-Samuel2 / VIA C3-Ezra (2001) Discrete microarchitecture (µ-op translation) 6th (PAE, speculative execution) 1995 Pentium Pro 32-bit ((14+32)-bit segmented) / 36-bit physical (PAE) µ-op translation, conditional move instructions, out-of-order register renaming, speculative execution, PAE (Pentium Pro), in-package L2 cache (Pentium Pro), Socket 8 1997 Pentium II/III, Celeron, Xeon SSE (2× 64-bit), on-die L2 Cache (Mendocino, Coppermine), SLOT 1 or Socket 370 1997 AMD K6/2/III, Cyrix III-Joshua (2000) 32-bit ((14+32)-bit segmented) / 32-bit On-die L2-Cache (K6-III, Cyrix III Joshua), 3DNow!, no PAE support, Super Socket 7 (K6-2) 2007 Dm&p vortex86 32-bit ((14+32)-bit segmented) / 36-bit in-order core with high pipeline, deep integrated with sound&graphic unit(SoC), on-chip memory controller, low clock, low power for embedded use. 6th/7th (μ-op fusion) 2003 Pentium M, VIA C7 (2005), Intel Core (2006) 32-bit ((14+32)-bit segmented) / 36-bit physical (PAE) Optimized for low thermal design power, four pumped FSB 7th (SMT, SMP) 1999 Athlon, Athlon XP Superscalar FPU, wide design (up to three x86 instr./clock), Slot A or Socket A 2000 Pentium 4 Deeply pipelined, high frequency, SSE2, hyper-threading, Socket 478 7th/8th (x86-64) 2005 Pentium 4 Prescott F/506/516/5x1/6xx, Celeron D 3x1/3x6/355, Pentium D 64-bit / 36-bit physical EM64T technology introduced, very deeply pipelined, very high frequency, SSE3, LGA 775 socket, CMP 8th (x86-64) 2003 Athlon 64, Athlon 64 X2 (2005), Sempron (2004), Opteron 64-bit / 40-bit physical AMD64 processor (excluding 32-bit Sempron), on-die memory controller, HyperTransport, CMP, virtualization (AMD-V) on some models, Socket 754/939/940 or AM2 socket 2006 Intel Core 2 64-bit / 36-bit physical Intel 64 processor, low power, multi-core, lower clock frequency, SSE4 (Penryn), wide dynamic execution, µ-op fusion, macro-µ-op fusion, virtualization (Intel VT) on some models 2007 AMD Phenom, AMD Phenom II (2008) 64-bit / 48-bit physical Monolithic quad-core, SSE4a, HyperTransport 3, AM2+ or AM3 socket 2008 VIA Nano 64-bit / 36-bit physical Out-of-order, superscalar, 64-bit (integer CPU), hardware-based encryption; very low power; adaptive power management 8th/9th 2008 Intel Core i3, Core i5 and Core i7 (Nehalem/Westmere) 64-bit / 40-bit physical QuickPath, native memory controller, on-die L3 cache, modular, Intel HD Graphics introduced onto CPU chip (Clarkdale), LGA 1366 (Nehalem) or LGA 1156 socket Intel Atom 32-bit ((14+32)-bit segmented) / 36-bit physical In-order but highly pipelined, very-low-power, some models (Diamondville)with 32-bit (integer CPU), on-die GPU (Penwell, Cedarview) 2010 AMD FX 64-bit / 52-bit physical highly pipelined, very-power hungry, extremely high clock, share instruction cache, first consumer octa-core processor, CMT(Clustered Multi-Thread), FMA, OpenCL, support up to 64 socket per chipset. 2011 AMD APU C, E and Z Series (Bobcat) 64-bit / 36-bit physical Out-of-order, 64-bit (integer CPU), on-die GPU; low power (Bobcat), Socket FM1 (Desktop) AMD APU A and E Series (Llano) 64-bit / 48-bit physical on-die GPU, first generation fusion APU 9th (GPGPU) 2011 AMD APU A Series (Bulldozer, Trinity and later) SSE5/AVX (4× 64-bit), highly modular design, integrated on-die GPU, Socket FM2 or Socket FM2+ Intel Core i3, Core i5 and Core i7 (Sandy Bridge/Ivy Bridge) 64-bit / 42-bit physical Internal Ring connection, GPGPU, LGA 1155 socket. 2013 Intel Core i3, Core i5 and Core i7 (Haswell/Broadwell) 64-bit / 44-bit physical AVX2, FMA3, TSX, BMI1, and BMI2 instructions, LGA 1150 socket 10th (SoC, MIC) 2015/2016 Intel Core i3, Core i5 and Core i7 (Skylake/Kaby Lake/Cannonlake) 64-bit / 46-bit physical Out-of-order, 64-bit (integer CPU), AVX3, integrated on-die southbridge, integrated on-die x86 MIC array GPU Others 2000 Transmeta Crusoe, Transmeta Efficeon 32-bit ((14+32)-bit segmented) / 32-bit VLIW design with x86 emulator, on-die memory controller 2001 Intel Itanium IA-32 compatibility mode 32-bit ((14+32)-bit segmented) / N/A EPIC architecture with an on-package engine (pre-2006 chips, later using IA-32 Execution Layer) that provides backward support for most IA-32 applications 2012 Intel Xeon Phi (Larrabee) 64-bit / 36-bit physical Many Integrated Cores (62), In-order P54C with x86-64, very wide vector unit, LRBni instructions (8× 64-bit)

I have some comments on this. (Feel free to move it, if placed in a wrong place. I'm also a bit unsure about commenting at all, because when I show the table, it shows a notice Please do not modify it.).

First, it's fine @Jeh: that you removed the Generation column. But on the other hand I did not actually know what the table was showing, until I saw this old version. After reading the lead to the table and looking at the content, it still seems to be very unclear what the purpose of this table is.

The best description I can find is your comment that it's supposed to be a "list of significant x86 developments". I will suggest two things.

1. Remove most of the information and keep just the "significant developments". Things when like 32-bit and 64-bit were first introduced and few other things will be fine, but maybe 90 % of the table is too detailed for this article.
2. Create a new article with a more detailed table (more columns), but it may not be necessary to include every x86 CPU, their features or instruction sets/extensions.

/PatrikN (talk) 04:41, 8 November 2016 (UTC)

Most of the details you want to remove are significant aspects of the development, i.e. things that differentiate the various model groups from each other. You just don't think they are. The whole point of a table like this is to present a great deal of information in an easily-browsed form. I don't see the point of splitting the table into a simplified version and a more elaborate version. We might as well keep the latter here. Jeh (talk) 04:54, 8 November 2016 (UTC)

Regarding modifications - as it says, the version of the table just before removal of the "generations" column is preserved here for reference. If you want to suggest changes, feel free to copy the existing table from the article itself into the talk page here and modify that. Because the "generations" column is not going back, the version of the table that's on this talk page and includes that column would not be a good starting point. Jeh (talk) 05:00, 8 November 2016 (UTC)

OK, when looking at it again, it might not be necessary to create a new extended table, but on the other hand, if you would like to keep columns like bit sizes and also add clock speeds, cores and more, I think it should be kept and extended in a new table. In this table, I don't see any "significant x86 developments" in listing and keeping e.g. 14 x 3 cells with almost the same information about 32-bit generation CPU's. I think it would be enough to just write the first time these things were used (which would be 32-bit instruction set on Intel 80386 and PAE on Pentium Pro).

In the same way, if this should not be a list of CPU family generations, all redundant and "non-improvements" should be removed. Some examples:

• Out-of-order is mentioned 4 times.
• Discrete microarchitecture (µ-op translation) is mentioned in 1996, but that's mentioned above for Pentium Pro, so isn't the 1996 entry just a list of non-Intel CPU's?
• no PAE support is obviously not an improvement, and just a comment about a CPU family, which would be fine in a list of CPU families, but not in a list of improvements.
• Words like deeply, high, highly and lower (including low power) are all relative words, which I think should be sourced with real numbers (or better, removed from here and eventually added to a separate table with extensive information).
• I'm also unsure if sockets is relevant here (as x86 developments or if that just is used/listed to describe the different CPU families).

But if, indeed, the table shall be a list of "processor models and model series" as it actually says now, then Intel Itanium IA-32 compatibility mode should be removed.

So first step to improve the table would be to decide what it will actually be a list of. Could it be as simple as to vote between these two alternatives? If you agree, then make your votes, otherwise comment on how to proceed.

1. CPU families (mostly like now)
2. Significant x86 developments (as Jeh described it)

/PatrikN (talk) 14:51, 8 November 2016 (UTC)

I'm not convinced that there is a large problem here that needs to be solved, at all. I am not voting for a way to change the table when you haven't made a case for changes in the first place.

I agree that there are some details in the table that could be presented better.

"Improvement" is your word, not mine. Omission of a feature previously introduced can be a "development", one of the defining aspects of a processor family, even though it isn't an improvement. Other valid changes to include here are max number of cores, socket type, etc.

You are correct that the table needs much improved sourcing, and not just for words like "deeply". (But e.g. "lower power than (some previous model series)", though relative, does not have to have real numbers to be meaningful.) Why don't you start by working on finding sourcing for all of the unsourced claims?

We are not going to remove anything from here and add it to another table with "extensive information". This IS the table with extensive information. There is flatly no need for any simplified version. Just ignore the columns you don't care about. Jeh (talk) 08:22, 9 November 2016 (UTC)

There are already lots of lists about microprocessors I can see now, so I still struggle to see what the purpose shall be for this list, but I suppose it can be some sort of summary of x86 microprocessors (or can it be distinguished and be just about the instruction set improvements?). Well, I'll go ahead and begin editing some now, instead of just talking /PatrikN (talk) 08:48, 10 November 2016 (UTC)

As for the table, please confine your experiments to the talk page. There is no consensus for changing the table on the article page. I really wish you would begin by adding references, which would not require preview here on the talk page. Jeh (talk) 09:03, 10 November 2016 (UTC)

Here is an idea for collapsing the "Linear address size (bits)" and "Segment / offset size (bits)" columns: Get rid of the latter, and in the former, the cells would have five different possible values: 16-bit, 16-bit with protected mode, 32-bit, 64-bit, and IA64 (IPF).

Then we have footnotes, or maybe a very small, second table, that gives the segment/offset size for each of these. For 64-bit it should say something like "14 / 32 bits in legacy mode, n/a in long mode". For IA64 it would say n/a.

Originally the many identical cells in these columns were collapsed by using vspans. I had to remove all of those to do the resequencing by strict chrnology, deleting all of the wildly-OR "generations", because the vspans have to be rethought once the rows are re-ordered. If you want to try putting the vspans back...

If we drop Itanium from this table then the IA64 designation goes away. It's in here in the first place because it does, after all, implement the x86 instruction set. Jeh (talk) 09:15, 10 November 2016 (UTC)

Just so you know, I have began looking at the other tables for references, and if I will do any experiment, I'll do it here on the talk page. I don't really get your idea about collapsing, but it sounds reasonable, so you are welcome to show it here. /PatrikN (talk) 10:59, 10 November 2016 (UTC)

Collapse is the wrong word, sorry. More like coalesce. With vspan (vertical span) you get a cell that is one column wide but as many rows high as you like.

The table has never been solely about ISA changes. A die shrink usually changes the ISA not at all but is usually a significant development that creates a new group of products. Jeh (talk) 11:15, 10 November 2016 (UTC)

Thanks for the clarifications! As I have suspected it was not only about ISA changes, so it was good to get that confirmed . /PatrikN (talk) 11:21, 10 November 2016 (UTC)

Speaking of die shrink, I think "feature size" should be a column. So should socket type. Jeh (talk) 20:08, 10 November 2016 (UTC)

Ridiculous, completely ridiculous! What a discussion involved almost only one user, Jeh! Is Jeh the dictator on Wikipedia.org? His words are the Bible? Ridiculous, Stupid, and nothing at all! --- Aaron Janagewen — Preceding unsigned comment added by 119.53.110.23 (talk) 23:43, 15 February 2017 (UTC)

What kind of Opteron has a PAE of 52-bit?

What kind of Opteron has a PAE of 52-bit? --- Aaron Janagewen — Preceding unsigned comment added by 119.53.110.23 (talk) 23:45, 15 February 2017 (UTC)

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)

Hello I fully vote IA-32 be merged with x86, which is were it should be. Both are 32bit. Furthermore, I propose to remove the x86-64 page altogether. Thanks.

@Guy Harris. "40 years of Software Development". Fighting this to the bitter, end I see.

Either that claim is a big fat lie or the last time you ran a compiler was sometime back around 2001. Are you retired? I don't think I've seen an x86-64 package since XP

As a software developer, you should know:

1, Intel Architecture Programming manuals use IA-32/IA-64 Intel-64 naming convention, not x86. Even the title itself is IA-32 Intel64.

2, In AMD's AMD64 Architecture Programming Manual, vol.2 there is not a single reference to x86-64.

Furthermore there is an entire chapter in AMD's System Programming Manual discussing the difference between legacy x86 architecture and AMD64 AMD64

3, Microsoft have native compilers for x86, IA-64 and AMD64 since K8. There is no x86-64 compiler. In fact MemInfo which is promoted on Microsofts Technet blog is compiled in 2 versions, one is AMD64, the other is Intel386. which is 32bit. There is no x86-64 compiler.

Microsoft MSDN software library there is no reference to x86--64.

x86, IA-32, are 32 bit. AMD64, x64, Intel-64 in 64bit.

Is there some other player we don't know about?

Seems this is a one man crusade to maintain confusion. Maybe contact Intel and ask to publish the next programming technical docs.

To Jeh:

x86-64 is THE industry standard? Which industry would that be exactly? Certainly not mine, which is ITIL Enterprise.

Do you believe our IT Managers weighing up the cost/performance benefit of Ryze were compring the new AMD's x86-64 against current Intel x86-64 line? No. What a ludicrous discussion that would be. Like who on first.

I doubt i7 Skylark is known as x86-64 i7 Skylark where you live. x86-64 is NOT "standard industry terminology".

All anyone need do is read the vendor published papers on Architecture to see that.

I'm surprised this merger is even up for debate. Thanks. 122.59.228.76 (talk) 02:30, 12 July 2017 (UTC)