Talk:X86/Archives/2016

Itanium
50-bits of physical memory addressing and 64-bits of virtual addressing

from itanium-9000-9100-datasheet.pdf and itanium-9300-9500-datasheet.pdf, useful or not. 119.51.184.193 (talk) 00:30, 15 February 2015 (UTC)


 * Perhaps useful on the Itanium page or the Montecito (processor) and Tukwila (processor) pages; not relevant to the very-definitely-non-IA-64/Itanium x86 instruction set so not useful on this page. Guy Harris (talk) 01:12, 15 February 2015 (UTC)


 * OK, this is another sock puppet of Janagewen, I am fighting for the fair and freedom of Wikipedia.org all the time for ever, OK, but is the information of that table relating with Itanium correct or not? 221.9.23.11 (talk) 01:18, 15 February 2015 (UTC)


 * It might depend on the chip and, in any case, unlike the Atom chips (which are standard x86 chips) and the Transmeta chips (which aren't supposed to run anything other than the Code Morphing Software and code that the CMS has translated natively; the operating system and application code that's run on it is IA-32 code). those Itanium chips that ran IA-32 code in hardware ran it as a compatibility mode, similar to PDP-11 compatibility mode on some VAXes, so the addressing limits for the IA-64/Itanium instruction set are completely irrelevant to its IA-32 engine, and don't belong here. Guy Harris (talk) 01:46, 15 February 2015 (UTC)


 * OK, I would wait till 15 April 2015 to blank the relate information on that table. — Preceding unsigned comment added by 221.9.23.11 (talk) 02:21, 15 February 2015 (UTC)

regarding protected mode
according to computer experts i talked to during the 90s protected mode was not available on the 80286. it was first available on the 80386. 84.213.45.196 (talk) 16:15, 9 July 2015 (UTC)


 * You presumably mean "experts", in quotes, as no actual expert, i.e. no actual knowledgable person, would say that. The 80286 most definitely did have protected mode - the reference for that on the protected mode page is:




 * What the 80286 didn't have was support for demand paging; it didn't divide any address space into fixed-length pages, each of which can be present in memory or absent.


 * It may not have been used as much on the 286 by the main operating systems for x86 processors, but there were definitely operating systems for the 286 that did use it, such as various UNIX ports and OS/2. Guy Harris (talk) 17:44, 9 July 2015 (UTC)


 * i tried to run games requiring protected mode on a 80286 and they would not work because it did not have protected mode. it could however run any super vga requiring game that did not require protected mode.84.213.45.196 (talk) 20:49, 9 July 2015 (UTC)


 * No, they didn't work because the 286 didn't have the right type of protected mode for the software you were trying to run. As the protected mode article says in the section on the 286:


 * The initial protected mode, released with the 286, was not widely used. It was used for example by Microsoft Xenix (around 1984), by Coherent, and by Minix. Several shortcomings such as the inability to access the BIOS or DOS calls due to inability to switch back to real mode without resetting the processor prevented widespread usage. Acceptance was additionally hampered by the fact that the 286 only allowed memory access in 16 bit segments via each of four segment registers, meaning only 4*216 bytes, equivalent to 256 kilobytes, could be accessed at a time. Because changing a segment register in protected mode caused a 6-byte segment descriptor to be loaded into the CPU from memory, the segment register load instruction took many tens of processor cycles, making it much slower than on the 8086; therefore, the strategy of computing segment addresses on-the-fly in order to access data structures larger than 128 kilobytes (the combined size of the two data segments) became impractical, even for those few programmers who had mastered it on the 8086/8088.


 * and the section on the 386 indicates that the 80386 fixed several of those issues - it offered a larger flat address space and made it easier to return to real mode from protected mode.


 * So your games that "required protected mode" really required the IA-32 version of protected mode, not just protected mode. Guy Harris (talk) 21:14, 9 July 2015 (UTC)


 * this. the inability of the 286 to switch from protected mode into to real mode (because that would have violated protection) made the use of 286 protected mode not backward compatible with x86 DOS. at that time, "IBM PCs" needed to be backward compatible to be successful in the market, so protected mode could only be used on the limited number of devices that didn't need DOS backward compatibility. — Preceding unsigned comment added by 96.246.59.19 (talk) 17:44, 11 October 2015 (UTC)


 * (Or on one of the limited number of IBM PCs that were running an operating system that didn't offer the ability to run arbitrary DOS applications, such as the various UNIX ports to the 286. But, again, "limited number", and you aren't going to be running DOS games there.) Guy Harris (talk) 19:16, 11 October 2015 (UTC)

Sources?
Originally I wrote -

''These "generation" numbers appear to have no reliable source and seem to have been made up. This issue has been brought up at least twice in the past and I've never gotten an answer. If reliable sources are not forthcoming I'm going to delete the column.'' Jeh (talk) 20:19, 21 September 2015 (UTC)

However, this complaint applies to the entire table.

This table has collected a tremendous amount of "information" over the years and not a single item in it has a source.

If sources are not forthcoming, the whole thing has to go. Just having a serial sockpuppet and a longtime editor agree on changes is not enough.

Also, this table falls into the "parts list" category. A table of model names and features is not encyclopedic. If you want to see how information like this should be presented, take a look at the History of IBM magnetic disk drives article. It describes the significant changes in the progression of development of this technology, with information about why each change was significant and how it was used. Sadly, that article is also mostly unreferenced, but that's another matter. Jeh (talk) 20:29, 21 September 2015 (UTC)


 * Hello! Well, we all know that providing sources is absolutely necessary in all articles.  The table provides a very good overview, there's no doubt about that, but it also needs sources. &mdash; Dsimic (talk &#124; contribs) 02:22, 9 October 2015 (UTC)


 * It's not just the lack of sources. The choice of assignment of various CPU models to "generations", with a single row for a single generation number and a single set of "notable features" supposedly applying to multiple vendors, is pure OR. Jeh (talk) 05:45, 19 January 2016 (UTC)

Is there anything wrong with this table?
In our high school. most students said this table is much better than the old one. So if someone want to get rid of it, please show the mistakes which this table has, please! — Preceding unsigned comment added by 46.105.38.84 (talk) 06:55, 22 December 2015 (UTC)


 * This article is subject to repeated attack by POV-pushing sockpuppets who don't know what they're talking about. As a result, so many changes in one edit cannot be accepted without discussion and evaluation by more seasoned editors. The opinion of your high school students (assuming you haven't just made that claim up) is, frankly, irrelevant.


 * Moreover, there was a fundamental problem with the table even before these changes: it is completely without references. Adding dozens of new unreferenced claims is not an improvement, no matter how correct or useful they turn out to be.


 * If you want to improve the table, add references for every claim in the existing table. Better do it soon: It's had a refimprove tag on it for months; if references don't show up soon I'm going to nuke the whole thing.


 * After that, we can talk about adding more referenced details. Jeh (talk) 07:28, 22 December 2015 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 2 one external links on X86. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive http://web.archive.org/web/20140319221015/http://bitsavers.trailing-edge.com/pdf/intel/80286/210498-001_1983_iAPX_286_Programmers_Reference_1983.pdf to http://bitsavers.trailing-edge.com/pdf/intel/80286/210498-001_1983_iAPX_286_Programmers_Reference_1983.pdf
 * Added archive http://web.archive.org/web/20100108075223/http://bwrc.eecs.berkeley.edu:80/CIC/announce/1999/k8.annc.html to http://bwrc.eecs.berkeley.edu/CIC/announce/1999/k8.annc.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.—cyberbot II  Talk to my owner :Online 09:34, 1 June 2016 (UTC)

Mention the x86 assembly language more
The x86 assembly language is only mentioned once in passing in the article, and once again in the "See also" section. I believe it is crucial that it is discussed in the article, and a clear distinction is made between "x86 as instruction set" and "x86 as assembly language".

72.230.215.230 (talk) 00:25, 9 July 2016 (UTC)


 * So what about the assembly language, as opposed to the machine language/instruction set, needs to be discussed here as opposed to being discussed in x86 assembly language? Guy Harris (talk) 00:45, 9 July 2016 (UTC)


 * I think the article has wide enough scope as it is. And as Guy noted, we already have the x86 assembly language article.
 * But an important overriding point for me is this: the "x86 assembly language" isn't really about the processor; it is purely an artifact of software (assembler, disassembler, debugger, etc.) and documentation. Let me put it stronger: As far as the processor is concerned there is no such thing as assembly language, any more than there is C or Java or PHP. There have been x86 assemblers (and disassemblers) that changed some of the opcode mnemonics, used different notation for operand specifiers, even reversed the order of operands (eg MOV src dst instead of MOV dst src). So there is no such thing as the x86 assembly language. This article, on the other hand, is about the processor itself. So I think these are fundamentally different kinds of topics. Jeh (talk) 00:53, 9 July 2016 (UTC)


 * Well, the assembly language is a tool for coding, while an architecture is the mechanism providing the fundamental resources for coding. Assembly Language might have different styles irrelative with the actual architecture, such as Intel Assembler and GCC Assembler, they both use the different grammar, but do actually assist coding for the same architecture. So emphasising something relative but not substantial tends to be meaningless, and few mentioned is just enough! Rechnerfan (talk) 15:59, 9 July 2016 (UTC)


 * I find it odd though that the MIPS instruction set page includes a big section devoted to the assembly language. Perhaps because there aren't many different assemblers with distinct syntaxes available for MIPS? 72.230.215.230 (talk) 17:59, 11 July 2016 (UTC)


 * Probably because there isn't a separate article on the MIPS assembly language, as there is for x86. And no, we're not interested in merging that into here. Jeh (talk) 18:27, 11 July 2016 (UTC)

Virtualization or Virtualisation?
Well, frankly, both are correct. They both are widely used in British and American English, but the former is a little bit more popular! Rechnerfan (talk) 15:51, 9 July 2016 (UTC)


 * When we're writing about x86, we look at the defining documents of x86. Those are written by AMD and Intel, They use the spelling "virtualization". Wikipedia follows its references. Jeh (talk) 18:25, 11 July 2016 (UTC)

Done

AMD Liano and 64-bit Virtual Address
Well, frankly, AMD Liano has only implemented 40-bit physical addressing bus, even though its core are commonly considered as 10.5h, and sorted into the kind of 10h. No matter K8 or 10h, Hyper Transport unit is an unseparated part of the underlying architecture, but AMD Liano and further APU lack this very thing. So they are different from the real AMD 10h microarchitecture. As to the first generation of AMD APU for desktop, 40-bit physical addressing bus later was succeeded by Bulldozer based APU with fully implementation of 48-bit one.

As to the Virtual Address, shall we mentioned only 48-bit implemented to avoid the ambiguity? As to the AMD64 or x86-64 architecture, expanding 48-bit to the fully 64-bit is not an easy job for the architects, and until this moment, no practical news from AMD or Intel, imply how and when the 48-bit would be expanded or extended to the long expecting 64-bit... Rechnerfan (talk) 16:15, 11 July 2016 (UTC)


 * You have this backwards. It would be a very easy job "for the architects": Simply follow the model that was used in going from 32 bits to 48 bits - add another two layers of page table. But nobody is "long expecting" 64 bits v.a.s. to happen anytime soon. For now, for the vast majority of users and uses, the biggest benefit of having a 48-bit address space is simply that ASLR now has far more room to play in. Consider that to actually populate (as opposed putting only 32 or 36 bits' worth of stuff in it, but with lots of holes) a 48-bit address space you would have to have 256 TiB of actual storage - some amount of RAM, plus enough disk space to hold the rest. Just because it's paged doesn't mean it doesn't have to have someplace to be stored; paged just means it doesn't all have to be in RAM at once. Jeh (talk) 18:37, 11 July 2016 (UTC)

this is speculation about possible future developments - talk page discussion is supposed to be about how to improve the page

AMD Liano and 64-bit Virtual Address
Well, frankly, AMD Liano has only implemented 40-bit physical addressing bus, even though its core are commonly considered as 10.5h, and sorted into the kind of 10h. No matter K8 or 10h, Hyper Transport unit is an unseparated part of the underlying architecture, but AMD Liano and further APU lack this very thing. So they are different from the real AMD 10h microarchitecture. As to the first generation of AMD APU for desktop, 40-bit physical addressing bus later was succeeded by Bulldozer based APU with fully implementation of 48-bit one.

As to the Virtual Address, shall we mentioned only 48-bit implemented to avoid the ambiguity? As to the AMD64 or x86-64 architecture, expanding 48-bit to the fully 64-bit is not an easy job for the architects, and until this moment, no practical news from AMD or Intel, imply how and when the 48-bit would be expanded or extended to the long expecting 64-bit... Rechnerfan (talk) 16:15, 11 July 2016 (UTC)


 * You have this backwards. It would be a very easy job "for the architects": Simply follow the model that was used in going from 32 bits to 48 bits - add another two layers of page table. But nobody is "long expecting" 64 bits v.a.s. to happen anytime soon. For now, for the vast majority of users and uses, the biggest benefit of having a 48-bit address space is simply that ASLR now has far more room to play in. Consider that to actually populate (as opposed putting only 32 or 36 bits' worth of stuff in it, but with lots of holes) a 48-bit address space you would have to have 256 TiB of actual storage - some amount of RAM, plus enough disk space to hold the rest. Just because it's paged doesn't mean it doesn't have to have someplace to be stored; paged just means it doesn't all have to be in RAM at once. Jeh (talk) 18:37, 11 July 2016 (UTC)

this is speculation about possible future developments - talk page discussion is supposed to be about how to improve the page

Pentium MMX in Chronology table
In the "Chronology" table, it says the Pentium MMX debuted in 1993, but the P5 (microarchitecture) article says it came out on October 22, 1996 and that date has a citation. Seems like it should be changed. Bumm13 (talk) 22:40, 20 October 2016 (UTC)


 * Thanks for the catch! Let's try to find some other sources to confirm. Jeh (talk) 00:33, 21 October 2016 (UTC)


 * The issue there might be that all P5s are being lumped together in that entry; the original P5 came out in 1993, but the MMX processors came out later. If the MMX deserves an entry of its own - which, as it was, I think, one of the early "multimedia" instruction sets, it might - that entry would have 1996. Guy Harris (talk) 01:25, 21 October 2016 (UTC)

Pentium MMX in Chronology table
In the "Chronology" table, it says the Pentium MMX debuted in 1993, but the P5 (microarchitecture) article says it came out on October 22, 1996 and that date has a citation. Seems like it should be changed. Bumm13 (talk) 22:40, 20 October 2016 (UTC)


 * Thanks for the catch! Let's try to find some other sources to confirm. Jeh (talk) 00:33, 21 October 2016 (UTC)


 * The issue there might be that all P5s are being lumped together in that entry; the original P5 came out in 1993, but the MMX processors came out later. If the MMX deserves an entry of its own - which, as it was, I think, one of the early "multimedia" instruction sets, it might - that entry would have 1996. Guy Harris (talk) 01:25, 21 October 2016 (UTC)

Core 2's physical address is 40bit
core 2 has been 40bit ever since woodcrest, even intel's officisl em64t demonstrated it can address up to 1 TB ram. Only older yamhill/ia32E have 36 bit address. — Preceding unsigned comment added by 2601:243:403:E1B0:A54B:6340:AF33:21E7 (talk) 20:16, 12 May 2016 (UTC)


 * I agree that QPI is not a bus. And I wouldn't call it "QPI bus". It's an interconnect and that word is already in "QPI".


 * Regarding 36 vs 40 bit, I don't know - I haven't looked at the Intel specs, and I don't have time for it now. Jeh (talk) 18:44, 7 July 2016 (UTC)


 * The Core microarchitecture supports 40-bit physical addresses in some implementations.


 * As far as I know, none of the "Core 2" implementations of the Core microarchitecture do; Woodcrest is a Xeon, not a Core 2.


 * See "Physical address sizes in Chronology table" below. Guy Harris (talk) 00:41, 24 October 2016 (UTC)

Physical address sizes in Chronology table
The Core microarchitecture can support up to 40-bit physical addresses, e.g. in the Xeon 7200/7300 series, but not all processors with cores with that architecture do, e.g. the Core 2 desktop/laptop processors and the Xeon 5100 series.

So should the physical address space column for a given microarchitecture give only the largest physical address supported by any implementation of that microarchitecture (with a citation), or should it give all the different physical address sizes for different implementations (with citations)? I made the current row for "Core 2" do the latter 1) to show that there are Core microarchitecture chips with 36-bit physical addresses and Core microarchitecture chips with 40-bit physical addresses and 2) to show what it looks like. I think "what it looks like" is "a bit cluttered", so perhaps the column should just show the maximum physical address size. Guy Harris (talk) 00:37, 24 October 2016 (UTC)


 * Maximum PA size works for me. The column heading could have a footnote indicating that some implementations may not support the max (and some chipsets limit PA to less than what the processor supports). Jeh (talk) 17:12, 28 October 2016 (UTC)

Improving the lead and whole article
After reading this article, the two about the 32-bit and 64-bit variants - currently titled IA-32 and x86-64 - and some other relevant information (Wikipedia articles and Intel manuals) for a few hours, I must admit I'm still a bit confused, e.g. about the naming conventions. I will try to come with some suggestions here and in a few other places.

There is an archived discussion here, where I think there are some good points and a few suggestions, but I can't see the outcome and I don't understand why the first comment is stroke out.

Some articles on Wikipedia I just think contains too much information, like details and history. This topic I think is an example of that.

When I think of x86, I think of it like a platform (or architecture) that's widely used today for personal computers, and that's it different from PowerPC and ARM (on different devices), which prevents something developed for one platform to be used on another. I also think about the difference between 32-bit and 64-bit as a current and very common issue. Therefore I think the lead of the article should focus more on these things, instead of things like 8-bit processors. This kind of details can be saved for the history. Generally there is too much difficult-to-understand terminology in the first section I think.

I also think it should be written some more that x86 are also used widely for the 32-bit generation. Another important thing I think is missing, is Apples switch to x86, which is the latest "historical part" of the Macintosh.

Another thing I would like to see, is two sections about the 32-bit and 64-bit variants, which have separate articles. The main points from these (and this article) I think deserve their own sections, considering their importance, like I also said before.

Finally I can see there are two Overview sections, which I suppose there shouldn't be.

I'll be happy to help to improve this article and come with some more concrete suggestions to what I have written, but first I just wanted to write this, with my intentions.

/PatrikN (talk) 03:13, 8 November 2016 (UTC)


 * "When I think of x86, I think of it like a platform (or architecture) that's widely used today for personal computers, and that's it different from PowerPC and ARM (on different devices), which prevents something developed for one platform to be used on another."


 * That's an accident of history. The personal computers are the platform; there have been systems using x86 processors that were not IBM PC-compatilbe, whether they're personal computers or bigger machines.  However, the non-compatible personal computers died off quickly, and, for the higher-end machines, it became, I think, easier to build something compatible with a Really Big PC than to have to, for example, get a Windows NT HAL for it.


 * For PowerPC, the only significant Personal Computer that used it was the Mac, and Apple was not particularly interested in clones. There wasn't a PPC-based platform until the PowerPC Reference Platform, which wasn't a real success; its successor, Common Hardware Reference Platform wasn't a success, either.   The Macintosh clones were probably the closest thing to a successful platform, but Steve Jobs killed that.  The Power Architecture Platform Reference may be a success, but only for server platforms.


 * For ARM, Acorn did the Acorn Archimedes, but I don't think they had any interest in it being a platform for anybody other than Acorn. I think ARM's biggest successes were in embedded systems and phones (feature phones and smartphones), and I don't think there's been much of a tendency for a "platform" for either of them.


 * So there's x86, the family of instruction set architectures, which is just like the 32-bit and 64-bit PPC/Power ISA and the ARM architectures and various other instruction set architectures, and there's x86's "PC platform", for which there aren't successful equivalents for other ISAs. There really needs to be at least some discussion of x86 as an ISA, independent of the rest of the PC platform; my inclination would be to leave the discussion of the platform either on the IBM PC compatible page, or on another page as that page seems mainly to be a page about the history of that platform, rather than the details.  That page would be equivalent to the PReP, CHRP, PAPR, Advanced RISC Computing, etc. pages, which describe attempts to, well, "clone" the success of the PC platform (most of which failed, even though the original "it just happened this way, we didn't try to design a platform" PC platform was a huge success). Guy Harris (talk) 04:14, 8 November 2016 (UTC)


 * The lede should be a summary of the most important points in the rest of the article. If the lede reflects the rest of the article, then the lede is correct. If the article body is significantly changed, then modify the lede accordingly. Working on the lede apart from the rest of the article is the wrong way to approach it. Jeh (talk) 04:50, 8 November 2016 (UTC)


 * Thanks for the feedback and sorry if misusing the term platform, where I might have meant architecture (also noted in parenthesis). I really try hard to understand what you mean and what the x86 article is about. Is it just an article about the instruction set, or is/should it also be about x86 (compatible) CPU's, the x86 "PC platform" and x86 operating systems?


 * If this article is intended to be strictly (or primarily) about the family of instruction set architectures, then it might be better to rename it to "x86 architecture" and create separate articles about the other uses for x86.


 * /PatrikN (talk) 21:31, 8 November 2016 (UTC)


 * This article is about the family of ISAs.


 * What are the "other uses for x86"? The "PC platform" should probably have a page, but the title of the page shouldn't necessarily have "x86" in it - an x86 processor is only one of the components of that platform; at this point in time, you would also probably need particular support chips and either a classic BIOS or an EFI boot ROM in order to be able to support the "PC-platform" binary distributions of various OSes "out of the box". Guy Harris (talk) 21:54, 8 November 2016 (UTC)


 * Well, there is also:
 * x86 hardware (processors) / x86-compatible processors - processors running/compatible with the x86 instruction set, and also SoC
 * x86 software (binaries) - software running on x86 hardware
 * x86 assembly language
 * x86 virtualization
 * x86 systems - x86 hardware running x86 software
 * /PatrikN (talk) 23:56, 8 November 2016 (UTC)


 * Well, three out of five of them already have articles about them.


 * I don't see a need for the "x86 software" page - there's a lot of software running on various x86 systems, including, at the operating system level, RMX/86 and at least some versions of DYNIX, and, at the application level, on various operating systems. There's not much to say about "x86 software".  One might be able to say something about "Windows software" or "Linux software" or "Mac software", but, for Linux, most of it is only "x86 software" for the versions compiled for x86 (there's nothing x86-specific about it), and the same applies to software for Macs during the transition-to-Intel period.


 * And, for x86 systems, there's "PC-compatible systems" (which I think some big servers might be, these days) and "other", and the only thing they have in common is x86 processors; I'm not sure that really makes both categories worthy of a single page. There should be at least one page talking about the PC platform - with, as I indicated, a title that probably doesn't include "x86" - and a single page for the other systems would just be a random collection of hardware from smartphones to Sequent servers to.... Guy Harris (talk) 00:14, 9 November 2016 (UTC)


 * Well, what I think is missing, is the "overview" of the different "topics", since this page now is focused on the ISA. If you compare with the ARM architecture and SPARC, these are more "all-round" and have sections about e.g. 32-bit architecture and Operating system support. /PatrikN (talk) 00:29, 9 November 2016 (UTC)