Talk:X86

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)

'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

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)

Reading articles on Wikipedia.org should be treated as reading some a Novel, such as Dracula. So there is no need tagging! — Preceding unsigned comment added by 221.9.13.240 (talk) 14:26, 15 April 2017 (UTC)

AMD Hammer and 40-bit!

There is no doubt, all AMD Hammer processors are equipped with 40-bit addressing bus, could be utilised by PAE and 64-bit mode addressing, no matter AMD Athlon 64, Sempron, Athlon FX, Opteron and so forth. There never exist processors based on AMD K8 equipped with 36-bit addressing bus!