Talk:X86/Archives/2018

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Recent disruptive editing

Hey guys.

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

Thanks in advance, guys.

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

First, the IP is clearly an SP of long-indef-blocked LTA Janagewen and is simply not permitted to edit. See here.
The "generations" column always was always largely unsourced. Janey once admitted as such in an edit comment, noting that he'd simply assigned various processor models to certain "generations" based on his own whim. There are no references I've been able to find for any notion of "generation" numbers that are common to and agreed upon by multiple manufacturers, not for more recent series anyway. Accordingly I removed the column with this edit. This was further discussed here on the talk page - it's now in the 2017 archive. There is consensus for a table without the "generations" column, a "Chronology" table sequenced by year. Janagewen continues to try to edit-war his own version of the table into the article, which version now includes many other changes, also undiscussed, unreferenced, and supported only by Janagewen's views of the industry, which are unique to say the least; see for example this. I recommend WP:RBI. Jeh (talk) 13:25, 10 June 2017 (UTC)
@Jeh: I see. It think I am familiar with Janagewen. But I didn't know the generation column was OR because I kept running into generation numbers in various articles, e.g., "The Athlon 64 is an eighth-generation, AMD64-architecture microprocessor produced by AMD". Or Intel, which keeps saying things like "2nd-Generation Intel Core i5". I didn't know there is no global pattern. FleetCommand (Speak your mind!) 06:52, 14 June 2017 (UTC)
It appears that from sources like industry trade journals there was general agreement on "generation numbers" through about the 7th - AMD's K7 achieving near feature parity with Intel's "seventh" gen. But with AMD haring off to do x64 while Intel made only an "8th generation" 32-bit CPU, it was no longer possible to say "this one is like that one, because they're both of the same generation". Which made the column not only unsourced, but uninformative. I suppose we could restore it if we qualified the gen. number, for 8th gen and later, by manufacturer, but again, good sources would have to be found. Yes, it is possible to source statements like "2nd-Generation Intel Core i5". But it is not, as far as I can tell, possible to relate that to a series of non-product-line-specific gen. numbers. Certainly we are well beyond the "2nd generation" in the x86/x64 world! In the meantime, ordering the table by introduction date seems sufficient. And even if we do find a way to include a well-sourced "generation" column I would argue that the table should not be sorted thereby, since at this point they're basically marketing names. Jeh (talk) 07:05, 14 June 2017 (UTC)

^The "architecture" is x86/IA-32 or Intel64 or AMD64. There's nothing more to say. And when did "Trade journals" become a source? What trade journals anyway? The only sources relevant are architecture papers published by AMD and Intel.

And I'll overlook the last two highly exaggerated claims. No doubt you believe it. Besides I probably deserved a snarky reply. Anyway lets try keep further dialogue civil. The COI allegation is not personal. 122.59.228.76 (talk) 12:09, 9 August 2017 (UTC)

Use of the non-manufacturer-specific term "x86" is completely justified per WP:COMMONNAME. Besides, did you know that Intel's IA32 processors and AMD's 32-bit x86 processors are not 100% compatible? Ever hear of MSRs? For example, Intel's use SYSCALL, while AMD's use SYSENTER, and these require the use of different MSRs. So if we use IA-32 we're ignoring AMD's products. Wouldn't that be biased toward Intel, against AMD? I certainly think so. But wait: wasn't it you awhile back who was complaining that I was using Intel references to the exclusion of AMD's?
I'm not arguing with you further about the merge/rename issue. The merge proposal has been closed as no consensus. You lost.
I'll overlook the last two highly exaggerated claims. Oh, you will!? Why, thank you! Imagine my relief!
In case you aren't sure, that's sarcasm.
(Whatever those claims are. You hop between topics like a jackrabbit and I'm not spending any mental energy trying to figure out what you're talking about so as to answer whatever.) Jeh (talk) 13:10, 9 August 2017 (UTC)

"Designers" of x86

Template:Infobox CPU architecture says that the "designer" field is for the "Designer of the architecture". Intel, obviously, were the original designers, and AMD originally designed the 64-bit capabilities.

Somebody added VIA Technologies to the list of designers "since they have released a new CPU based on x86", but that's not what "designer" means in this infobox. However, they appear to have made their own additions to x86, such as VIA PadLock. Is that sufficient to qualify them as a "designer", or do extensions have to be adopted by at least one other x86 vendor, or by Intel itself (as was the case with the AMD-designed 64-bit version), to qualify the designer of the extensions as a designer of x86 itself? Guy Harris (talk) 20:14, 7 January 2018 (UTC)

That isn't so obvious. To me, x86 means everything from the 8086 on, and so the designer should be the designer of the 8086. Everything later is just extensions to the original design. IA32 is an officially named architecture, so should have an official designer. (Which might just be Intel corp.) Gah4 (talk) 20:26, 7 January 2018 (UTC)
So there's:
  • "x86-16", clearly designed by Intel;
  • IA-32, clearly designed by Intel, based on the Intel-designed "x86-16";
  • x86-64/AMD64/Intel 64, clearly designed by AMD, based on the Intel-designed IA-32;
  • x86, an umbrella name covering all three of the above (similar to, for example, "System/3x0" covering everything from System/360 either to System/390 or to z/Architecture).
So how exactly should that be presented? Guy Harris (talk) 21:09, 7 January 2018 (UTC)
Whatever the answer to that, VIA certainly does not belong here as a peer to Intel and AMD in the list of "designers". 21:58, 7 January 2018 (UTC)

Merger proposal

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

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

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

  • As proposer, I'd also like to specifically open the door to alternatives to this merge, such as splitting out content from this article which is specific to IA-32, merging that into the IA-32 article instead. Right now, x86 is a large article, and IA-32 is a quite small article, do we have the appropriate balance? Murph9000 (talk) 23:42, 17 May 2017 (UTC)
  • information Note: for convenience and context, I've added article links to the top for much of the extended family and related, which have appeared in the ongoing discussion. Murph9000 (talk) 10:50, 19 May 2017 (UTC)
  • Oppose per WP:SIZERULE. x86 is already too large. It cannot accommodate this article with all its details. FleetCommand (Speak your mind!) 23:57, 17 May 2017 (UTC)
    @FleetCommand: Ok, so do you see any scope for splitting content from this article into IA-32 instead? Murph9000 (talk) 23:59, 17 May 2017 (UTC)
    As a matter of fact, I do. Sections "32-bit" and "Protected mode". The latter is already a summary-style section, so even content duplication would do, although I'd do some adjustments. FleetCommand (Speak your mind!) 00:06, 18 May 2017 (UTC)
  • Theoretically, the x86 article should be the 8086 and all its decendants, while IA32 is only the 32 bit extension. Even more, the x86-64 article should only be the 64 bit extensions to IA32. I suspect that too many people say (and link to) x86 when they mean IA32. Gah4 (talk) 00:27, 18 May 2017 (UTC)
  • Thinking about this more, x86 could be a disambiguation page to 8086 (including 8088), 80186, and 80286 pages. Then the IA32 page for the 386 up to, but not including, the 64 bit architecture. Where reasonable, don't discuss items from previous processors, but reference the appropriate page. Gah4 (talk) 00:27, 18 May 2017 (UTC)
    • "x86" is widely used in the industry to cover processors all the way from the 8086 through the latest Cores and Ryzens; making it a dab page for only the 16-bit x86 processors would be misleading. Guy Harris (talk) 00:46, 18 May 2017 (UTC)
      • I didn't mean only those, but the later ones are described by the appropriately named architecture, instead of individual processors. But links to the processors would also be fine. Gah4 (talk) 01:27, 18 May 2017 (UTC)
        • I.e., you meant "x86 could be a disambiguation page to 8086 (including 8088), 80186, and 80286 pages, and the IA32 page for the 386 up to, but not including, the 64 bit architecture"? The first sentence was followed by a sentence fragment, so it wasn't quite clear. If so, what should be done about x86-64? Link to that as well?
  • If we had a "16-bit x86" page, discussing the versions of the x86 ISA in the 8086/8088, 80186/80188, and 80286, we'd then have pages for all three variants. The "Addressing modes" section could then be carved up and put into "16-bit x86", IA-32, and x86-64; the same could be done for the "16-bit", "32-bit", and "64-bit" sections of "x86 registers". The "Structure" section could also show the 16-bit, 32-bit, and 64-bit structures.
But that might involve duplication of information in ways that don't fully show the continuity between the three versions of the ISA. Guy Harris (talk) 01:03, 18 May 2017 (UTC)
I think showing the continuity is important. Jeh (talk) 05:12, 18 May 2017 (UTC)
  • I still vote for x86 as a disambiguation page. After that, I am somewhat open to what goes where. Some compromise between excessive duplication and not enough continuity. It looks to me like 8086 and 8088 do a fine job of balancing the two, with the latter mostly about the differences, and reasons behind them. Well, maybe slightly more than the usual disambiguation. It could have a little on the generalities of 16 bit, 32 bit, and 64 bit intel processor series', with the details going into linked pages. Date ranges, and the reasons behind going to the next series would seem about right. Note also that with each generation, a large fraction of users used it just as a faster version of the previous system, and not actually using the added features. Gah4 (talk) 14:31, 18 May 2017 (UTC)
I see no justification whatever for changing x86 to be a disambiguation page. It's not just an industry-standard term, it's the industry-standard term for this series of architectures and the processors that implement them. Specific implementations like 8086 but there is no need to have a DA page over them - the table here does a good job and provides far more info for selecting among them than a DA page is allowed to have. (There are limits on the format and content of DA pages.) Jeh (talk) 15:15, 18 May 2017 (UTC)
Hmmm. There are lots of references to x86 inside intel.com, but mostly in forums, written by non-intel people. Some people do use x86 as a synonym for IA-32, but it should really be used for the whole series of processors, 8086 and its descendants. But OK, not exactly a disambiguation page, but with enough detail to separate the different processors and architectures, leaving the details to the individual pages. So, maybe one paragraph each for 8086 through 80286, linking to its page. Then a longer description of IA-32, as an architecture, with a link to its page, along with smaller descriptions of the processors implementing it with links. And then the history (from AMD64 to EM64T, Intel64 and x64) of 64 bit processors. Maybe also a description of IA-64, and where it belongs in the series. Do note that Windows 10 won't run on an 8086, no matter what you call it. Most 32 bit Windows systems will run 16 bit (MS-DOS days) code, but later 64 bit versions of Windows won't. More than the usual disambiguation, enough details to direct people to the appropriate page, and some history of what came when, and why. Actual details such as register names and opcodes should go on the linked pages. Gah4 (talk) 16:26, 18 May 2017 (UTC)
To be more specific, about the first third of the page seems about right. After that, it is too detailed by about a factor of 2 or 3. Details about register bits and such could go on other pages. Gah4 (talk) 16:48, 18 May 2017 (UTC)
I see no advantage in that. Anyway, that is off-topic from the question of whether to merge IA-32 to here. You're talking about a major reorg of this page, including splitting it up into multiple other articles. I can't see how moving e.g. the register names and opcodes out of this page impinges on that question. Jeh (talk) 12:46, 19 May 2017 (UTC)



First - I apologise in advance but I double posted this down below .

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 all use IA-32/IA-64 Intel-64 naming convention, not x86. Even the title is IA-32 Intel64 Architecture

2, In AMD's AMD64 Architecture System Programming Manual, vol.2 there is not a single reference to x86-64. Furthermore there is an entire chapter dedicated to clarify the difference between legacy x86 architecture and AMD64.

3, Microsoft have had native compilers for x86(Intel386)and AMD64 since K8. Obviously the instructions set are different. x87 FPU is a prime example. 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.

Microsoft MSDN software library there are no references to x86-64.

x86,IA-32 is 32bit. AMD64, Intel-64 is 64bit - x64 is marginally acceptable. There is no middle designation of x86-x4.


Is there some other player in the industry we don't know about? AMD and Intel should have the right to call their own CPU's whatever they want. Not what Wikipedia and a few forums decide.

Seems this is a one man Guy Harris crusade to maintain confusion. Maybe call Intel and ask to publish their next technical docs. 


@Jeh:

As for x86/ x86-64 being industry standard, which industry would that be? Maybe in your industry but certainly not mine, which is ITIL Enterprise. 

Do u think IT Managers sat at lunch weighing up the cost/performance benefit of AMD's latest x86-64 against the current Intel x86-64 line when Ryzen arrived? No.

What a conversation that would be,

I doubt i7 Skylark is known as x86-64 i7 Skylark where you live. 02:48, 12 July 2017 (UTC)122.59.228.76 (talk)

The tone in which the above is expressed suggests to me that 122.59.228.76 is WP:NOTHERE to participate collaboratively and with WP:CIVILlity. Sounds more like a WP:BATTLEGROUND attitude to me. Jeh (talk) 23:07, 13 July 2017 (UTC)
Regarding "x86-64", deleting that article and merging it here is flatly not going to happen; it is simply too large and describes something that's too different. The IP is perhaps unaware that "x86-64" was AMD's original name for the architecture (perhaps because she or he has not read x86-64). Anyone interested in renaming that article now should probably read the history at the talk archives under that page. Probably at talk:x64 too. At this point I would support moving it to [[x64]. Jeh (talk) 00:42, 14 July 2017 (UTC)
And the x86-64 has the redirects from em64t and EM64T, the older Intel names for it. The 32 bit description and 64 bit description are at least big enough for their own pages. I am still not so sure what to do with the 16 bit chips. There needs to be an appropriate compromise between duplication of information and excessive page size. Gah4 (talk) 01:32, 14 July 2017 (UTC)
And WP:COMMONNAME. It is completely true that "x86" is neither AMD's nor Intel's name for ... whatever it's a name for. Nevertheless its usage is very widespread. Jeh (talk) 01:58, 14 July 2017 (UTC)
As far as I know, trying to remember that long ago, x86 was already the name when the choices were 8088 and 80286. And then there was the 80386 which most people ran MS-DOS on, in 16 bit real mode, as a fast 8088 (or 80286). For many years (maybe still now) MS software specifies the 80386 as its minimum requirement, as the need for a 32 bit system. Gah4 (talk) 03:04, 14 July 2017 (UTC)

@Jeh

"The tone in which the above is expressed suggests to me that 122.59.228.76 is WP:NOTHERE to participate collaboratively and with WP:CIVILlity. Sounds more like a WP:BATTLEGROUND attitude to me."

Ok in answer to your question yes I'm aware of the history behind x86-64 naming convention, myself I have been in the business since around 1998. It was the unofficial press-release name for AMD64. No doubt you will be aware x86-64 in SYSTEM_INFO is obsolete and deprecated officially by MS...... :)

I understand rewriting might be a lot of work but should the time it takes to update a page take precedence over the relevance of the article?

Also... have no idea what those tags mean, but if you're implying I have a sour attitude ....yes I suppose I can't deny that.. :p Nothing personal, but perusing the computing articles I have noticed several inaccuracies which have never been corrected by editors who (I would hope) are experts on the subjects they regularly edit.. I find this rather frustrating tbh..

For example the first paragraph of this article states "with memory segmentation as a solution for addressing more memory than can be covered by a plain 16-bit address", which a not true. Quite a significant oversight actually. 

"Memory" is RAM, and RAM is accessed through an external data bus, more RAM requires more bus lines.

Segmentation allows bank switching between 2GB memory banks, using 16bit PTE's and a segment pointer, which conceptually is the same as paging from a HDD. It does not allow more memory (RAM) to be used.


This is why kernel and usermode were split into 2GB segments, until AMD64 introduced the flat model (I imagine you know this already).

I believe a more accurate description for the above would be "with memory segmentation as a solution for addressing more "physical address space"", not "more memory". Since physical space covers HDD and RAM both. In this case though it extends address space via the HDD for paging (pagefile) What are your thoughts? 122.59.228.76 (talk) 15:16, 2 August 2017 (UTC)

Sorry, but I think that just about everything you've written here shows that you have many mistaken ideas. And some that are worse than merely mistaken; they show a fundamental misunderstanding and faulty assumptions about just about everything you've mentioned. In short you do not seem to me to be qualified to evaluate articles in this area, let alone suggest changes. (See WP:CIR)
Just for example: you wrote: Segmentation allows bank switching between 2GB memory banks, using 16bit PTE's [...] Reality is that there has never been a "16bit PTE" in the history of x86. Not with the first x86's that implemented segmented addressing, not with x64, not with anything in between. And that's not the only thing wrong with that claim.
It [x86-64] was the unofficial press-release name for AMD64
Yeah, so unofficial that AMD sent out bound hardcopies of their architecture manuals (five perfect-bound volumes each around an inch thick) with the name "X86-64" plastered all over them, including the titles. LOL!
myself I have been in the business since around 1998.
Yeah, that's cute. I've been in the business - and by that I mean low-level system programming - since around 1974. And working with segmented memory since, hm, 1977 (HP 21MX) and with virtual memory (again, low-level system programming) since 1981 (VMS).
Regarding the tags, just click on them. They're links. Jeh (talk) 06:23, 3 August 2017 (UTC)
  • Comment I don't know about IA-32, but x86-64 should definitely have its own page, because there is so much more information about it and it is sufficiently different from x86. Also, the 8086 and others listed are chips, not ISAs, while IA-64 is completely different than anything x86. So idk why they're listed. Wqwt (talk) 00:09, 28 March 2018 (UTC)

Relevance of Plan 9

If we consider Plan 9 to be relevant, then we surely should consider other operating systems with a similarly sized user base to also be relevant (for instance: Haiku, ReactOS...) I only see one (1) IP that added Plan 9 to the article alongside major operating systems such as Windows, Linux, BSD, and Solaris, without explaining the reason behind it except for "add plan 9." Sure, Plan 9 isn't irrelevant (in general), but, as I already stated, it is irrelevant to this article alongside other major operating systems.

Personal note: The loud community of Plan 9 fans that has been recently booming shouldn't be a justification for these kinds of edits. If Plan 9 gets added, then surely other operating systems deserve to be added as well, and if any fan base of any operating system started doing that, the page would end up a mess. This is just Plan 9 for now, but it might very well be another operating system tomorrow, and I'd like to prevent that from happening.

With this, I will undo your undo for now. Please reply here for further discussion. — Preceding unsigned comment added by Woosh1 (talk • contribs) 20:24, 22 April 2018 (UTC)

As I noted on your talk page, please become familiar with WP:BRD. By re-reverting to your preferred version, twice now (not counting your original edit), you are well started down the "edit war" path. Edit warring, even without reaching the "four reverts in 24 hours" "bright line", is considered disruptive. (See WP:EW)
You should have come here with your argument after you were reverted the first time.
I see no evidence that "The loud community of Plan 9 fans that has been recently booming"[citation needed] is responsible for, or used to justify, "these kinds of edits" - whatever you mean by that. (Is that kinda like "those people", by chance?) By the looks of things I have no more reason to think that you are any less POV-pushing than the person who added "Plan 9".
My evaluation is that although Plan 9 does not have a large user base, there is no question that it is historically significant in many ways, as detailed at its article. As a fully-featured Unix-based OS, released as open source, widely used as a research and teaching platform, that runs on the most successful desktop/laptop computer architecture ever, how can you say it's irrelevant to that platform? Jeh (talk) 21:04, 22 April 2018 (UTC)
Once again, I'm sorry about the double revert. My mistake for not being familiar with WP:BRD and WP:EW.
My "these kinds of edits" comment was referring to POV-based edits according to personal preference (which should be avoided according to WP:POV).
Then I agree with the last paragraph about the relevance of Plan 9. Woosh1 (talk) 21:30, 22 April 2018 (UTC)
How do you know that the edit to add Plan 9 was a "POV-based edit according to personal preference"?
And why should anyone think your deletion of references to Plan 9 is anything but a POV-based edit based on your "personal preference"?
Especially given your very WP:POINTY attitude toward the anon and to "the loud community of Plan 9 fans"? Jeh (talk) 22:35, 22 April 2018 (UTC)
And why do you think "refrain my undoing my work" (as you commented here) should be a compelling argument for leaving your version alone, when you didn't have a bit of a problem with undoing the work of the IP who added Plan 9? At least they added material (with a proper pipelink and everything). All you did was hit the "undo" button. Jeh (talk) 23:47, 22 April 2018 (UTC)

Chronology : Remove IA-64 and ARM?

In the Chronology section, I expected to see a chronology of x86 architecture. I was suprised to see that IA-64 and ARM made the list. I understand that IA-64 and ARM added either hardware or software compatibility with x86 instructions set, but wouldn't be simpler and more straightforward for readers if this chronology only tells about x86 processors only? — Preceding unsigned comment added by 174.91.223.158 (talk • contribs) 05:04, 19 June 2018 (UTC)

I thought I would agree, but it looks like IA-64 is an important part in the evolution of x86. Not counting table entries, it looks like two paragraphs. This describes Intel's decisions along the way. As for ARM, I suppose it could do without it, but mostly it is saying that x86 isn't ARM. Gah4 (talk) 06:10, 19 June 2018 (UTC)
No. IA-64 (Itanium) was not "part of the evolution of x86", it is a completely different architecture. Heck, the architecture design didn't even originate at Intel, but rather HP. The only relation it has to x86 was as an attempt to do things very very differently, plus support for x86 compatibility (for which performance was very poor). Intel's decisions re Itanium belong in its own article. Similar comments re ARM. They should both go. Jeh (talk) 06:13, 19 June 2018 (UTC)
It is a failed branch of where Intel intended to go. Enough is needed for the context of those failures. Otherwise, there is no explanation for why AMD came out with AMD-64, now called x86-64, before Intel. I suspect that Intel believed that IA-64 would be built sooner, and that x86 performance would be better. The fact that it wasn't built sooner, and x86 performance was poor, is important for x86 evolution. Looking back, it is easy to see the problems, but also easy to forget them. (That is, so such mistakes don't happen again.) It needs to be here at least to explain that IA-64 isn't the Intel name for x86-64. Gah4 (talk) 15:30, 19 June 2018 (UTC)
But does it need to be in the Chronology section? IA-64 is mentioned in x86#x86-64:
In 2001, Intel attempted to introduce a non-x86 64-bit architecture named IA-64 in its Itanium processor, initially aiming for the high-performance computing market, hoping that it would eventually replace the 32-bit x86. While IA-64 was incompatible with x86, the Itanium processor did provide emulation capabilities for translating x86 instructions into IA-64, but this affected the performance of x86 programs so badly that it was rarely, if ever, actually useful to the users: programmers should rewrite x86 programs for the IA-64 architecture or their performance on Itanium would be orders of magnitude worse than on a true x86 processor. The market rejected the Itanium processor since it broke backward compatibility and preferred to continue using x86 chips, and very few programs were rewritten for IA-64.
AMD decided to take another path toward 64-bit memory addressing, making sure backward compatibility would not suffer. In April 2003, AMD released the first x86 processor with 64-bit general-purpose registers, the Opteron, capable of addressing much more than 4 GB of virtual memory using the new x86-64 extension (also known as AMD64 or x64). The 64-bit extensions to the x86 architecture were enabled only in the newly introduced long mode, therefore 32-bit and 16-bit applications and operating systems could simply continue using an AMD64 processor in protected or other modes, without even the slightest sacrifice of performance and with full compatibility back to the original instructions of the 16-bit Intel 8086. The market responded positively, adopting the 64-bit AMD processors for both high-performance applications and business or home computers.
Seeing the market rejecting the incompatible Itanium processor and Microsoft supporting AMD64, Intel had to respond and introduced its own x86-64 processor, the "Prescott" Pentium 4, in July 2004. As a result, the Itanium processor with its IA-64 instruction set is rarely used and x86, through its x86-64 incarnation, is still the dominant CPU architecture in non-embedded computers.
so I see no reason to leave it in the chronology of x86 implementations. Guy Harris (talk) 18:20, 19 June 2018 (UTC)
It is a failed branch of where Intel intended to go. Not where "Intel intended to go with x86". Intel is not equivalent to x86. This article is about x86, not Intel. Itanium doesn't belong in the x86 chronology table. Jeh (talk) 19:16, 19 June 2018 (UTC)
As well as I know it, Itanium (that is, before Itanium 2) has hardware support for IA-32. That seems to be not well documented on Itanium. Starting with Itanium 2, it is software emulation only. And by the way, there are plenty of mentions of AMD and x86-64 on the Itanium page, including mentioning which OS run x86-64. (I suspect that the latter is not needed and distracting.) In the case of other processors, the table mentions them almost at the individual stepping level, but all of Itanium in one entry. As only Itanium 1 (that is, Merced) has hardware support, it seems that the entry should only cover that, along with appropriate date range. In the case of ARM, it is also describing software emulation. Gah4 (talk) 20:25, 19 June 2018 (UTC)
If we bother to cover the Merced implementation of IA-32, we should note that this is referring only to the backwards-compatibility part of the processor, describe it as an IA-32 implementation - i.e., give the instruction set as "32-bit x86", not "IA-64" - and in "Notable features" describe only the IA-32 part of the implementation (which means removing "64-bit EPIC architecture, 128-bit VLIW instruction bundle").
I wouldn't bother with software implementations; otherwise, we'd have to include, for example the Mac version of Virtual PC and QEMU and so on. Guy Harris (talk) 20:50, 19 June 2018 (UTC)


The VAX-11 processors can run PDP-11 code. That doesn't mean that a table showing the chronology of PDP-11 processors should include the VAX-11. I can't think of any reason to mention software emulation - any general purpose processor can emulate any other. This table is about the chronology of x86 processors, not emulators thereof. As for other pages, that's those other pages' problems. This table isn't required to repeat their mistakes. Jeh (talk) 21:43, 19 June 2018 (UTC)

The Intel Itanium Architecture Software Developer’s Manual, revision 2.3 says

IA-32 operating system resources; IA-32 paging, MTRRs, IDT, control registers, debug registers and privileged instructions are superseded by resources defined in the Itanium architecture. All accesses to these resources result in an interception fault.

in section 6.2.1.2 "IA-32 Instruction Set Execution" when talking about the hardware IA-32 support in some Itanium processors, so Merced can't function as a full IA-32 processor, running an IA-32 operating system; all it has is the ability to run IA-32 applications under an IA-64 operating system.

This was, as I remember, also the case with the PDP-11 compatibility in the VAX, so the analogy seems complete, supporting the argument that we should not bother to mention even just Merced in the list of IA-32 generations. Guy Harris (talk) 22:25, 19 June 2018 (UTC)

@Guy Harris:, please do not be so sure about your wrong conclusion with improper documentations to reference! When in late 2004, I installed an x86 or 32-bit version of Windows Server 2003 onto one HP Itanium based server! Early Itanium based platform provided two operating environments, Itanium environment (which you mentioned and discussed on the above) and IA-32 environment. The latter is provided by the firmware rather than the O/S, it is something quite like today's CSM, which enable x86 O/S to run on EFI platform. I suggest you reference the early versions of Itanium architecture manual from Intel for related information! That is the very reason I placed the Itanium onto that table, which I have maintained for years! 221.9.13.137 (talk) 15:19, 23 June 2018 (UTC)

So the January 2000 Intel IA-64 Architecture Software Developer's Manual, Volume 4: Itanium Processor Programmer's Guide indicates that "The Itanium processor is capable of executing IA-32 instructions in the IA-32 system environment (legacy IA-32 operating systems) provided the required platform and firmware support exists in the system."; "the Itanium processor" refers to Merced - section 1.4, "Overview of Volume 4: Itanium Processor Programmer's Guide" says "This volume describes model-specific architectural features incorporated into the Intel Itanium processor, the first IA-64 processor". That document also indicates that "When RESET# is asserted, all IA-64 processors boot in a different reset location than IA-32 processors and start executing 64-bit IA-64 of IA-32 16 bit Real Mode code.", so Merced can't be made to start up as an IA-32 processor - in order to boot an IA-32 operating system, some firmware or software would need to switch to the IA-32 system environment.
So Itanium processors that support the IA-32 system environment (not just supporting IA-32 non-privileged code in the Itanium system environment) could perhaps be listed in the table, although the entry should only discuss the IA-32 aspects of the processor.
The current version of the Itanium Architecture documentation speaks only of the Itanium system environment, so they've dropped the IA-32 system environment. Guy Harris (talk) 18:45, 23 June 2018 (UTC)

"Generation" column again

How did this completely unreferenced bit of stuff-someone-made-up-one-day get back in here?

This is how: https://en.wikipedia.org/w/index.php?title=X86&type=revision&diff=844673781&oldid=843473014 Another Janagewen IP sock.

It's going away. There is no reference for industry-wide "generation" numbers. Jeh (talk) 19:32, 19 July 2018 (UTC)

Fixed: Large number of problems in the chronology table

Hello.

I fixed a large number of problems in the Chronology section. Here is a detailed list of what has gotten fixed:

  • Erroneous info: IA-64 and ARM64 were framed into the chronology, in a way that implied they were implementations of x86! And that's the smallest problem; this integration was so weird, it was analogous to reading an article on the life of Bill Gates that frequently strayed off the topic to explain the details of Beyonce's life in parallel. Whatever the noble motive of the original writer, the end result grossly failed to justify itself.
  • Writer's pet peeves: Apparently the writer had felt the need to emphatically explain that "x64" is part of "x86". But the irony is this act would backfire because the integration of erroneous info about IA-64 and ARM64. It is like the story of the boy called wolf for the third time; when you (by mistake or intentionally) tell people that IA-64 and ARM64 are part of x86, and they find out otherwise, they don't believe you when you tell them x64 is an x86 version.
  • Ambiguous info: Intel Core i3, i5 and i7 are CPU brand names, not CPU models; these brand names have been used since 2008 for the bulk of Intel products. I replaced them with the Intel CPU architecture names, e.g., Nehalem.
  • Conflicting top and bottom headings:
    • "Generation" ≠ "Era" (one is time, one is the product of it)
    • "Introduction" ≠ "Release" (one happens once, the other can happen repeatedly afterwards)
    • "Prominent CPU models" ≠ "CPU models" (not every CPU is prominent)
    • "Address Space" ≠ "Physical Address Space", especially when right below the former, it says "Physical", "virtual" and "linear"
    • "Notable features" ≠ "New features" (one feature can be new but not notable)
  • Contested info: Please read previous discussions in this talk page
  • Editorializing (e.g. "Enhanced Platform", which is zero-informative. Proof: [1])
  • Broken links
  • Incorrect use of slash; see MOS:SLASH
  • Capitalization; see MOS:CAPS
  • "NA" → "{{N/A}}"

5.78.104.231 (talk) 08:35, 28 August 2018 (UTC)


@5.78.104.231: I've no comments about your words, but would you please design or devise completely a new table rather than modifying mine? 221.9.14.156 (talk) 23:32, 4 September 2018 (UTC)

You (221.9.14.156) are quite obviously the long-permanent-blocked Janagewen (see user:Janagewen, WP:Sockpuppet_investigations/Janagewen/Archive, etc.). You are permanently blocked from editing due to a wide variety of problems, as detailed at your various case pages. I have therefore reverted your change and will continue to do so. Jeh (talk) 00:51, 5 September 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:X86/Archives/2018&oldid=1150653899"