Talk:X86

Archives (Index)

2011 2012 2015 2016 2017 2018 2019 2020 2021

This page is archived by ClueBot III.

Not every Atom 64bit

Someone must fix table. Also Bulldozer and Piledriver(still not in table) are pure CPUs not APUs. — Preceding unsigned comment added by 188.162.36.100 (talk • contribs) 03:39, 13 September 2013 (UTC)

Perhaps User:188.162.36.100 should fix it? Guy Harris (talk) 03:53, 13 September 2013 (UTC)

Generations

Hi, how were those x86-Generations established? Does anybody have a Source on this? They just seem strange to me... --Pentiumforever 21:00, 3 January 2007 (UTC)

They were not. It's basically just ad hoc retroactive labeling. — Preceding unsigned comment added by 83.253.229.56 (talk) 17:42, 5 August 2014 (UTC)

x87

Apparently the x87 instruction set was integrated into the x86 chips; this is not explained in the article. -- Beland 14:00, 24 July 2007 (UTC)

amd k10 is the first 9th generation x86 processor to reach the market in the form of opteron barcelona core. since no desktop product have yet reach the market and intel have not introduced equivalents as of now we shouldn't add it to the chart. however amd k10 is definitely not an 8th generation cpu. —Preceding unsigned comment added by 160.94.27.159 (talk) 22:38, 25 October 2007 (UTC)

Still ,its not clear at all now whether a CPU that claims to be "x86 compatible" should per-definition support a floating point instruction set extension. Can a CPU claim to be "x86 compatible" while NOT incorporating a floating point processor? Mahjongg (talk) 12:54, 21 August 2008 (UTC)

What is the x97 architecture a follow on or posterior processor family? It seems to be aun unofficial x87 succesor Dabenavidesd (talk) 22:40, 30 May 2012 (UTC)Dabenavidesd

Disambiguation of binary prefix

I just added a couple of footnotes to explain the binary meaning of MB, GB etc. I then noticed that the binary forms GiB, TiB are used explicitly later on in the article. I think it would be better to choose between the two disambiguation styles and then apply it consistently. Are there any views on which of the two styles is preferred? Thunderbird2 (talk) 11:42, 20 April 2008 (UTC)

There isn't a lot of guidance in WP:MOSNUM#Binary prefixes, but consistency is definitely preferred. My personal preference is for GiB, etc., on the basis that a) given the article content, we can reasonably assume a fairly technical readership; and b) if we find that we need footnotes to clarify a term, that's a good indication that we ought to use a more clear term. Jakew (talk) 12:01, 20 April 2008 (UTC)

Hey that was quick :) It's true there's not much guidance from MOSNUM, but that's not for lack of trying. There's been a huge amount of debate there recently, but little consensus (yet). If the x86 readers will understand GiB (or at least take the trouble to read gibibyte) it would certainly read better without the footnotes. Thunderbird2 (talk) 12:07, 20 April 2008 (UTC)

Oh my, I had no idea that this subject was so sensitive! Can I propose waiting for a few days, to see what other editors think? Jakew (talk) 12:24, 20 April 2008 (UTC)

Sensitive? Some people have it has their religion. Soon they'll be demanding tax deduction.--Anss123 (talk) 12:29, 20 April 2008 (UTC)

It depends on what the sources use. At the moment it looks like the sources mostly use GB, so using GiB in the article would make it inconsistent with those sources. Fnagaton 14:01, 20 April 2008 (UTC)

I reckon the professional and academic literature is tending more and more to use IEC prefixes, which I feel should be preferred for this article. Here are some examples

• Buntinas et al
• Eeckhout et al
• Ganssle & Barr
• Georges et al
• Kuszmaul
• Rauch

Thunderbird2 (talk) 21:00, 20 April 2008 (UTC)

Which of those sources are used by this article though? This source, cited by the article, uses GB. Fnagaton 21:16, 20 April 2008 (UTC)

What if some sources use GB and others use GiB? It seems to me that the result would be rather confusing. To my mind, except for direct quotes, it makes sense to standardise on one or the other. Jakew (talk) 21:22, 20 April 2008 (UTC)

Which sources used by the article use GiB? Fnagaton 21:24, 20 April 2008 (UTC)

What matters is the reliable literature aimed at this level of readership. Just one or two more ...

• Chanet et al
• Coutinho et al
• Desnoyers & Dagenais
• Engel & Mertens
• Ericsson
• Gara et al
• Gleixner et al
• Heimpold & Baumgartl
• Heirman et al
• Heander & Malmborn
• Moreira et al
• Parthey & Baumgartl

Thunderbird2 (talk) 21:41, 20 April 2008 (UTC)

• All: One’s sources is only part of the equation. Often the source you are quoting helps to discern who your target readership is. I would suggest that the true test of the wise thing to do here is to decide whether this article is truly directed primarily to an expert audience, such as professional software developers, or is really directed to a general-interest readership. Who is the audience? Does this article seem like it would most likely belong to part of a registered-membership Web site for software developers (?) or does this article look more like the sort of thing you would read in an in-depth article in PC World? If the latter, what unit symbols would PC World use and how would they disambiguate (if at all)? Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. I don’t profess to know the answer to who the readership truly is in this case; it seems, however, to be a general-interest readership to me though. Greg L (talk) 21:46, 20 April 2008 (UTC)

• Yes, that's a good point. Looking through the article I think anyone capable of reading and understanding it would probably already be familiar with MiB, and if not, he (I hope that's not considered sexist - it's unlikely to be a she) could easily lap up the concept in between bites of shreddies for breakfast. Thunderbird2 (talk) 21:57, 20 April 2008 (UTC)

• T-bird, I agree that this article quite arguably enjoys a relatively pro audience that can swallow and digest “GiB”. Accordingly, I see no reason to take a stand of any sort on this one as it is quite fairly a judgment call. Having stipulated that a pro audience can “swallow and digest” the unit, is a separate issue from whether it is most wise to feed it to them; clearly, a pro audience would also have reciprocal-infinity trouble with “A 32-bit address space would allow the processor to directly address only 4 GB of data.” The advantage of this wording, of course, is it is all the more accessible to a less knowledgeable readership. In the final analysis, I would argue the real test here is a tradeoff on Wikipedia’s fundamental mission, which is: A) so that readers can learn about a subject and B) are primed as well as possible to learn even more in their studies elsewhere. In other words, will a reader who has learned a great deal in this article, later encounter “GiB” most often in his studies elsewhere on this subject? If so, use of GiB is good. Quite good. But the second, “B” consideration must be weighed against the possible confusion with the “A”-side of the equation: looking out for relatively novice readers trying to make heads or tails of this complex topic. I don’t know the answers to any of this as the true answer relies entirely upon fact: what sort of articles for further reading are really likely to be encountered and what units do they use? I do however, believe this is the proper way to frame and evaluate the problem. Greg L (talk) 23:46, 20 April 2008 (UTC)

• P.S. I’ve withdrawn my vote in the survey. Thunderbird2 is using the proper process in evaluating the issue: who is the audience? Upon further looking at the article, it appears that a good case can be made that it is directed to a professional audience. Fnagaton: this is a poor choice of an article to make war on the IEC prefixes. As long as the authors here are properly considering who the audience is, that’s all we can fairly ask. I suggest you let them do as they see fit in this case and direct your energies on an egregious example that needs fixing. I do wish you’d chill a bit until MOSNUM#Follow current literature has better taken root. Greg L (talk) 21:55, 20 April 2008 (UTC)

---

Let's have a quick survey. Thunderbird2 (talk) 21:05, 20 April 2008 (UTC)

Survey

I think this article should use MiB, GiB, TiB ... to disambiguate

1. While I recognise the desire to follow the current literature, Thunderbird2 has shown numerous examples of current literature that uses GiB, etc. While we could examine the sources currently cited in this article, it therefore seems likely that (even if we don't already do so) we will sooner or later cite a source using the IEC units. Unless we wish to use inconsistent units (which would be very confusing), we therefore have to choose. I see our role as to clearly and precisely express the subject matter. While I recognise that an explanatory footnote helps, I think that use of ambiguous units (eg., GB) does not help the reader. Also, I think that we can assume a reasonably technical audience, who will likely be familiar with GiB, etc. (and if not, will likely follow a link as an opportunity to learn). Apologies for the not-very-brief explanation. Jakew (talk) 11:41, 21 April 2008 (UTC)
2. Clarity. I'm a strong supporter of IEC 60027-2. --217.87.99.52 (talk) 20:15, 21 April 2008 (UTC)
3. Reasoning per Jakew. Thunderbird2 (talk) 18:12, 21 April 2008 (UTC)
4. <your signature here (+ brief explanation)>
5. When trying to write consistent engineering documents that use both physical units and computer terminology, the inconsistency between say MW and MB is glaring and the IEC standards begin to make much sense. That this is primarily a computer oriented article insulates it from the need to disambiguate metric from base 2. However this is not a sound plan for the consistent use of units on Wikipedia. The sooner we use K consistently for Kilo and Ki consistently for 1024, the better. — Preceding unsigned comment added by David in oregon (talk • contribs) 06:39, 25 April 2012 (UTC)

I think this article should use MB, GB, TB ..., and disambiguate with an explanatory footnote

1. Fnagaton 21:16, 20 April 2008 (UTC)
2. Anss123 (talk) 22:18, 20 April 2008 (UTC) (It's rear to see GiB used anywhere but here)
3. A footnote is much more clearer than GiB.DavidPaulHamilton (talk) 23:22, 20 April 2008 (UTC)
4. Oh, well then. After reading Jakew’s vote above, I see that no one has yet identified a cited source that uses the IEC prefixes. That changes things: facts I didn’t have before. Besides, the test isn’t where any source uses them, but what most of the sources cited in this article are using. Anywhere else, that would normally quickly settle the issue of what is the proper terminology and units of measure we should be using here to most easily communicate to this readership. Greg L (talk) 03:03, 23 April 2008 (UTC)
5. Common usage is MB, not MiB, and until the IEC terminology is standardized I believe this should revert to MB/GB/TB with footnotes. Resuna (talk) 00:24, 17 June 2008 (UTC)
6. Oh, no, do not let this slip in through the back door again, after years of fighting this bad bad bad idea. Common use is NOT to use GiB KiB etc, never seen it used in common computer magazines, never expect it to see it either, if it was bound to happen it should have happened by now. except perhaps in an article that explains the discrepancy in hard-disk capacities, and then only in a theoretical setting, as in "some experts use the term MiB". its NOT used in common conversation. P.S. I see, I reacted to an old thread, no use starting it up again. Mahjongg (talk) 17:33, 11 January 2009 (UTC)
7. <your signature here (+ brief explanation)>

I think this article should use MB, GB, TB ..., with some other form of disambiguation (please specify)

1. <your signature here (+ brief explanation)>

---

Where do we go from here?

That seems fairly evenly balanced. May I gauge the strength of your views?

The act of disambiguation is more important than the manner in which it is achieved

1. Ambiguity is the root of all evil.Thunderbird2 (talk) 19:52, 21 April 2008 (UTC)
2. <your signature here (+ brief explanation)>

IEC prefixes should never be used

1. DavidPaulHamilton (talk) 22:50, 21 April 2008 (UTC) If you must disambiguate it serves the reader to use the more familiar method. IEC is not familiar so do not use it.
2. The use of the non IEC prefixes is so ingrained, and with it the knowledge that it means binary, that using a different unit will only confuse. IEC prefixes are only for purely academic (rocket science) purposes, not for common conversation. Mahjongg (talk) 17:38, 11 January 2009 (UTC)
3. <your signature here (+ brief explanation)>

Ambiguous prefixes should never be used

1. <your signature here (+ brief explanation)>

I cannot identify with any of the above (please clarify)

1. This is a muddy grey area. I believe that arguments over the inherently ambiguous nature of the standard prefixes, while true, have become way overblown; their shortcomings largely an issue of our own making (the rest of the general-interest publishing world manages well enough with “GB”). The most important objective is to not confuse the readers. Who are the readers in this case? What can cause confusion in this case? Some would argue that “a 32-bit address space is 4 GB” causes confusion for an expert readership and this overrides concerns that “a 32-bit address space is 4 GiB” will be unfamiliar to less knowledgeable readers. I’m not sold on that reasoning yet; the whole article is clearly dealing only with binary address space. Still, given that this article is clearly directed to an advanced readership, the scales are not wildly imbalanced here. I have my idea as to the better solution but I have no problem with GiB for this article. Greg L (talk) 20:22, 21 April 2008 (UTC)
2. I wouldn't go so far as to say that ambiguous prefixes should never be used. Having said that, I'm not convinced that using "GiB" will really cause confusion, for two reasons. First, we can't be sure that readers will even be familiar with "GB", and the prospect of avoiding prefixes altogether seems unrealistic. Second, this is an encyclopaedia, and surely as a general rule readers of an encyclopaedia want and expect to learn something, and aren't frightened of doing so (I suspect, but can't prove, that this is especially true of more technical audiences). As a general principle, we don't avoid unfamiliar units, but we do wikilink them. So to my mind to "harms" of using ambiguous prefixes are greater than the "harms" of using potentially unfamiliar prefixes, at least in this article. I do agree with Thunderbird2, though, that some form of disambiguation is essential, and I would also say that lack of consistency within the article is probably more confusing than one prefix or the other. Jakew (talk) 14:28, 22 April 2008 (UTC)

• We do avoid using unfamiliar terms for disambiguation though. The sources do mostly use GB.DavidPaulHamilton (talk) 15:14, 22 April 2008 (UTC)
• Jakew, I don’t think your position conforms to the basic principals of technical writing. Your position stated above: “as a general rule, readers of an encyclopaedia want and expect to learn something” says, in effect “let’s go ahead and teach readers about ‘GiB’ because they are good units and it’s so good for readers to know about them, we should use them in an in-your-face, routine fashion like ‘oh, didn’t you know(?), this is the way one communicates on this subject’.” But no encyclopedia—not even Wikipedia with the power of wikilinking to easily explain stuff—should try to teach terminology that even computer aficionados haven’t seen before and which no one will likely ever again encounter out in the real world after leaving Wikipedia. Wikipedia is the only animal around that would pull such a stunt. I would argue that Wikipedia’s use is not because there is a broad consensus of support to do so (far from it), but is because the proponents of using them strongly believe they are so good, our use here on Wikipedia might somehow bootstrap their adoption. It hasn’t worked so far. Since the proponents started using the IEC prefixes en-mass two years ago, there have been seven archives (B1–B7) dedicated to arguments over their use and at least two regular archives (97 & 98) also dedicated exclusively to the issue. Their use has been highly controversial on Wikipedia and we’re pretty much alone on this; no other encyclopedia uses them—and for good reason. Greg L (talk) 02:42, 23 April 2008 (UTC)

• Greg L, I'm afraid you've misunderstood my argument. I'm not saying that we ought to use these units because it is good for readers to learn about them. I'm saying that we shouldn't avoid using them just because they might be unfamiliar (as with, say, zettajoules, we should use the units when appropriate, but should make every effort to make it easy for readers to become familiar with them). Nor am I saying that we should bootstrap their usage; as Thunderbird2 has shown, these units are used in the technical literature, and there is every possibility that readers will come across them as they learn about the subject. What I am saying is that the harms of using these units seem somewhat overstated, particularly given the likely audience of this article. Jakew (talk) 11:47, 23 April 2008 (UTC)

Greg L, where can one read about these "basic principals of technical writing"? I don't see how it's possible to interpret Jakew's statement in the way you do. Aren't you just once more ridiculing a statement that you disagree with? You summarization of the previous discussion isn't only extremely single-sided, it's plain wrong. I don't even see why you're arguing that much about this case at all. Let's look at your very own proposed "guideline": Wikipedia_talk:Manual_of_Style_(dates_and_numbers)#First_draft. This article is about as close as it gets to x86 assembly language. So why are you opposing something that is perfectly in-line with your own proposal? --217.87.102.163 (talk) 19:55, 23 April 2008 (UTC)

1. "a 32-bit address space is 2³²B = 4,294,967,296 bytes = 4 gigabytes". HAHAHAA --212.149.216.233 (talk) 15:00, 22 April 2008 (UTC)

1. I believe that common usage should be followed. Neither format is ambiguous as used on this page with appropriate footnotes, so ambiguity is not an issue. In any case, GiB and MiB is still ambiguous because it doesn't specify the size of the bytes. There are still computers operating with non-power-of-two words and bytes, after all. But, you say, the x86 family isn't one of them, and common usage is for 8 bit bytes... why then, the x86 CPU is not a disk drive either, and common usage is for MB and GB to refer to power-of-two prefixes. Resuna (talk) 00:30, 17 June 2008 (UTC)

low cost niches

"Intel notoriously absent in low cost niches."

Home appliances are not low cost : a dish washer costs as much as a pc. Home appliances are not a niche: the total volume and costs dwarf the pc market.

This article has been written from the perspective of the PC, someone not realising how large embedded markets are: disk washers, central heating, all remote controlled stuff, cell phones, printers, routers etc etc

Windows CE is (regrettably as far as I'm concerned) making an inroad on embedded markets and makes Intel a player there, so also in this respect the statement is not accurate.

80.100.243.19 (talk) 10:58, 8 January 2010 (UTC)

Windows CEWindows Embedded Compact runs on ARM, so its presence in embedded markets is not, on its own, sufficient to make Intel a significant player.

In any case, the article now says

Modern x86 is relatively uncommon in embedded systems, however, and small low power applications (using tiny batteries) as well as low-cost microprocessor markets, such as home appliances and toys, lack any significant x86 presence. Simple 8-bit and 16-bit based architectures are common here, although the x86-compatible VIA C7, VIA Nano, AMD's Geode, Athlon Neo and Intel Atom are examples of 32- and 64-bit designs used in some relatively low power and low cost segments.

so it no longer speaks of niches. It does speak of "low-cost microprocessor markets, such as home appliances and toys"; as far as I know, "low-cost" modifies "microprocessor", not "market", but perhaps that should be phrased as "markets for low-cost microprocessors, such as...". Guy Harris (talk) 18:03, 5 August 2014 (UTC)

i havent ever encountered a 286 with protected mode.

i have encountered some really advanced versions of the processor but even the most advanced didnt have protected mode. i also knew a computer expert that said something about it only being in the 386. computer experts should be trusted. that makes it logical to assume that protected mode was added on the 386. —Preceding unsigned comment added by 84.208.86.142 (talk) 17:15, 29 April 2011 (UTC)

Your expert needs to check the docs more. 80286 CPUs implemented 16-bit protected mode. QNX used it for one of their 16-bit x86 OS. HumphreyW (talk) 17:22, 29 April 2011 (UTC)

That's right. If I were you, I'd never trusted your so called expert. 80386 implemented virtual mode. Fleet Command (talk) 18:35, 29 April 2011 (UTC)

i tried warcraft orcs and humans on a 286 but it didnt work because the pc didnt have protected mode.—Preceding unsigned comment added by 84.208.86.142 (talk)

Let's do this by the book. If you think 286 does not support Protected Mode you must cite from a Reliable source. Otherwise, these half-baked allegations are worthless. And by the way, Warcraft: Orcs & Humans requires at least a 80386 system. See its manual. Fleet Command (talk) 10:46, 30 April 2011 (UTC)

It's the other way around: if you think the 80286 supports protected mode, you must cite from a reliable source. It can be pretty hard to prove that something does not exist. 80.162.60.16 (talk) 02:38, 7 December 2011 (UTC)

OK, go look for "protected" in the 286 Programmer's Reference; you'll see lots of references to it. Guy Harris (talk) 05:39, 26 December 2013 (UTC)

Xenix used 286 protected mode back in the day [1]. 86.121.18.250 (talk) 05:33, 7 January 2014 (UTC)

Register Names

There is a reference to the control register CR8 (for 64-bit), but the page it links to on the subject has not mention of such a register. However it does have one called EFER. Are these the same thing (one by acronym, the other by index)? If so, can they be named consistently and/or the alias be included (e.g. "CR8/EFER" or "CR8 (aka EFER)") in both pages. If not, then can reference to both names be added as not to cause potential confusion that they may be the same thing, and act as a placeholder for details to be added in the future (if such a style is allowed).

Chad3f (talk) 23:18, 28 August 2012 (UTC)

What is the real 7th generation x86 processor?

Even though AMD named its K7/Athlon processor as the 7th generation processor, but it is only belonging to AMD x86 family, should not confuse with 7th generation x86 processor. Because in Athlon/K7, there is no outstanding thing making it prominent, and its CPUID tells us it is the only 6th generation processor comparing against Pentium Pro/II/III. And Intel Netburst microarchitecture based processor should not be counted as 7th generation x86 processor too. Intel ever called its Pentium 4 as P68, that is to say it is only one processor between real 80786 and 80686. And in fact of all, Intel Netburst uses very long and narrow pipelining, and its integer ALU core is only 16bit with double pumped clock. And from external view of Pentium 4 platform, it was only enhancing then-current P5/P6 bus architecture. And comparing to Intel P6, P68 or Intel Netburst is short-lived. Pentium 4 could only be treated as one temporary x86 generation between P6 and Core Microarchitecture.

From the aspect of CPUID, the first generation Itanium processor denoted as the 7th generation processor, but not x86 family even though with supporting Pentium III ISA. Maybe bit wdith expansion, such as from 8086(16bit) to 80286(16bit protected), or 80286(16bit protected) to 80386(32bit protected) could be used to differentiate processors in generations, but for the discrete microarchitecture desgin, that plays another role. Today simply multiplying same core(Dual/quad or many core processors) or purely fusion(such as Cyrix Media GX) should not be counted as one new generation processor.

Core 2 Duo/Quad, I don't think it is the 7th geneartion x86 processor, but enhanced 6th geneartion x86 processor. Core i7 derives from Core Microarchitecture, later versions integrating GPGPU, should this be the real 7th generation comparing with 80386 to 80486? But 80486 pipelining the internal core, what happens to Core i Series comparing Core 2 processors in microarchitecture design? Similar, only similar or enhanced. For my greatest apologies I don't know which is the real 7th geneartion x86 processor or 80786, is it still under design in Intel house for next few years? — Preceding unsigned comment added by Janagewen (talk • contribs) 09:46, 16 November 2012 (UTC)

A superscalar x87-part was definitely the defining new thing with the K7. (Although it also had a completely new external bus inherited from Digital Alpha (the K6 used the Pentium's bus) and more execution units than the P6, among others.) 83.253.243.39 (talk) 15:42, 30 July 2013 (UTC)

 Done Janagewen (talk) 23:57, 24 October 2014 (UTC)

If Intel named their Itanium processors as 80786, then what else would you consider? What does 86 in 80x86 mean? 8 means that the smallest bit with of a register could be referred, such as both AH and AL (high and low part of register AX) are 8-bit wide. And 6 means how wide the external data bus is, comparing against 8086(16 bits) and 8088 (8 bits), and 80386DX (32 bits) and 80386SX (16 bits). And in fact of all, since Intel 80486, this term 86 had already been meaningless, because 80486SX and 80486DX both have 32 bits width external data bus. And today how wide is the external data bus connected with the processor core when highly integrated? Password Saeba Ryo (talk) 10:47, 22 December 2014 (UTC)

Names of engineers who worked on x86?

I feel it would be great if the article x86 could also give some insight about the engineers who worked on x86, rather than just the companies. As the article is about the architecture rather than individual processors, we could focus on finding sources for the processors that had a significant impact in advancing the x86 architecture, such as the initial 16-bit 8086, the 32-bit i386, and the 64-bit AMD Athlon64/Opteron. One name that comes to mind is Vinod Dham but the article needs some clean-up and more work so I wouldn't feel like linking to it now. What other engineers, preferently with already existing Wikipedia articles or with reliable sources, could you suggest for an overview of engineers whose work had an impact on x86? Sofia Koutsouveli (talk) 18:52, 18 March 2014 (UTC)

This is A Potentially Ridiculous Article

Seriously, it is a potentially ridiculous article, and mislead readers to comprehend the word "x86", for the following reasons:

1. Should sort AMD64 or Intel64 implementations as x86? Generally "x86" was used to point all the processors compatible with IA-32 ISA, might or might name themselves with "86", such as Cyrix 5x86, Intel Pentium 4 and so on. AMD64's long mode is devised by AMD rather than Intel, so how can one sort them together. Nowadays software labeled themselves as "x86" are IA-32 compatible software, and use "x64" or "x86-64" differentiating with it. So this article confuses reader getting in touch with this word.

2. Generations? What is the 8th generation x86 processor? Who invented this kinda processors? AMD K8 just says that it succeeds AMD K7 rather than saying it is the 8th x86 processor, and I've never heard Intel call their x86 processors exceeding the 7th generation. And one thing should never be denied, the first generation of Itanium processor says its family model number as 7, which might potentially imply that Itanium might be the 7th x86 processor succeeding Pentium III, but none confirmed this. So take turn back the Transmeta's Crusoe and Efficeon, if the morph firmed on the system board implements x86 decoder call themselves as x86 processors, then if put the same processor on another board implementing PowerPC decoder, then it would be the PowerPC processor? At this situation, what kind of processor is it? Ridiculous! What's more for what sort it as the 7th/8th generation x86? Who is another Jane Austen, making up another Northanger Abbey?

3. "x86" is one architecture(ISA) name? What such a ridiculous thing that I've ever heard on earth! "x86" is used to referring the processor, a kind or series of processors rather than an architecture. If it were the name of an architecture, then in this logic way, Intel 80486 is one of the "implementation" of this "architecture"? Janagewen (talk) 11:49, 10 October 2014 (UTC)

 DoneJanagewen (talk) 23:58, 24 October 2014 (UTC)

I feel a little bit absurd, maybe this is an over idealised article. Another question would easily counter what this article tells. Let us reconsider an AMD Opteron processor: the question what we are interested is whether AMD Opteron is x86 processor? Yes, some are (AMD64); and no, some others(ARMv8) are not! Likewise, if we say x86 is a family of backward compatible instruction set architectures, here what is a compatible architecture? If we say Architecture Family, we would only refer to RISC, CISC, EPIC or something that kind; or else they are not Architecture Family at all. If two architectures are compatible, no matter from what direction, that would say that those two architectures are the same architecture but at different releases or versions. But as is known to us, AMD64 architecture is not compatible with IA-32 directly, only provides backward support at two levels: first, on the processor level, retaining the support for whole IA-32 architecture, making it works like a traditional x86 processor (through the microarchitecture desgin). Second, on the architecture level, providing the compatible mode to support most IA-32 software. And this compatible mode is not self-contained mode, and must be supplemented with the real 64-bit mode to provide essential and necessary background support. So from this aspect, I could hardly see AMD64 is a new revision of IA-32, so it could not be a generation of x86. Most modern processors are the realization of a fine devised architecture, such as Itanium; but x86 processors are different. This so-called x86 architecture is generalized and abstracted mostly from the real processors rather than those processors are, from the first day, designed to implement this x86 architecture except all the clone products. By analogy, why you could not sort Chinese and Japanese to the same language family, even though they look too similar and both use Chinese characters or Kanji heavily? Password Saeba Ryo (talk) 13:10, 22 December 2014 (UTC)

Hm, so what do you actually propose? — Dsimic (talk | contribs) 13:37, 22 December 2014 (UTC)

"This so-called x86 architecture is generalized and abstracted mostly from the real processors". Yes, that's what an instruction set architecture is all about - it's an abstract set of instructions, registers, memory management unit behaviors and data structures, etc. for which a programmer can write code and that is implemented by a number of different processors.

"AMD64 architecture is not compatible with IA-32 directly, only provides backward support at two levels: first, on the processor level, retaining the support for whole IA-32 architecture, making it works like a traditional x86 processor". Or making x86-64 a superset of IA-32, just as z/Architecture is a superset of System/390, and SPARC v9 is a superset of SPARC v8, and so on.

"And this compatible mode is not self-contained mode, and must be supplemented with the real 64-bit mode to provide essential and necessary background support." "Legacy mode" is a self-contained mode - you can boot a 32-bit or even 16-bit OS on an x86-64 processor without any use of long mode. Guy Harris (talk) 19:31, 22 December 2014 (UTC)

I am very sorry, if you guys want to confuse yourselves or fool around, I've no obligation to tell what is fact and what is correct. x86-64 is not part of x86, and they both are not the architecture names, only used to refer those kind of processors and associated instruction set(s) by metonymy usage. i386 is short for instruction set of 80386, similar with i486, i586 and i686, you can also use i786 to refer to Pentium 4 Willamette and Northwood, at least their internal integer ALU is 16bits double pumped. i686 is the superset of i486 for its instruction set, but their fundamental Instruction Set Architecture is IA-32. For AMD64 or Intel64 processors, Legacy IA-32 mode and Long Mode(or IA-32e Mode) could not be used simultaneous, users must switch in or switch out to the appropriate one. For AMD 10.5 Microarchitecture, DDR3 support is introduced alongside with DDR2, but they both could not be used simultaneously, so could you call this new introduced memory type (DDR3) the superset of DDR2? Turn back to the situation of Legacy Mode and Long Mode, they both are used to realized two architectures, IA-32 and AMD64, even though they both share the similar belief background, but they are two architectures, even though using x86 and x86-64 to denote them both, and there are no relation of inclusion at all.

Confusing metonymy usage with real architecture names, one hypothesized architecture with two separate architectures would mislead readers, general users to choose the wrong hardware and software to configure; programmers unable to adapt their programmes to the future platform. As a faithful reader of Wikipedia.org, and a computer science fan, I know I have to say all those words after I benefits from the pleasure of all those passed days! Password Saeba Ryo (talk) 00:52, 25 December 2014 (UTC)

Quite frankly, I've never heard or seen anyone using "786" to refer to a CPU or an ISA. When using an integrated memory controller (IMC) that supports both DDR2 and DDR3 memory as an example, DDR3 itself isn't a superset of DDR2, but that particular IMC's feature set is a clear superset of an IMC that supports only DDR2: one of them supports only DDR2, while the other one also supports DDR3. In other words, it's the IMCs what should be compared, not the memory standards. — Dsimic (talk | contribs) 04:28, 25 December 2014 (UTC)

Yes, "IA-32" is the 32-bit version of the instruction set, and "x86-64" is the 64-bit version of the instruction set (with "AMD64" and "Intel 64" variants"). "x86" is a name that refers to them and to the 16-bit version of the instruction set. Similarly:

• "SPARC v7" and "SPARC v8" (and the never-publicly-released earlier versions) are the 32-bit version of the SPARC instruction set, and "SPARC v9" is the 64-bit version of the SPARC instruction set, with "SPARC" referring to all of them;
• "PA-RISC 1.x" (for various versions of x) are the 32-bit versions of the PA-RISC architecture, and "PA-RISC 2.0" is the 64-bit version of the PA-RISC architecture, with "PA-RISC" referring to all of them;
• "MIPS I", "MIPS II", "MIPS III", and "MIPS32" are 32-bit versions of the MIPS architecture, and "MIPS IV", "MIPS V", and "MIPS64" bit versions of the MIPS architecture, with "MIPS" or "MIPS architecture" referring to all of them;

and so on. There should be, but isn't, a term that refers to all the architectures including the System/360 architecture, System/370 architecture, System/370-XA architecture, ESA/370 architecture, ESA/390 architecture (all 32-bit), and z/Architecture (64-bit).

If there are programmers who couldn't manage to adapt to x86-64 merely because we refer to the 16-bit, 32-bit, and 64-bit versions of the x86 architectures as "x86", then we need better programmers. Guy Harris (talk) 07:23, 25 December 2014 (UTC)

Maybe we both have opposite viewpoints to the same or similar things, so we could not use correctness or incorrectness to judge each other's. SPARC, PA-RISC and MIPS are the architecture names since the very beginning, and all of them are almost open architectures. But 8086, 80186 (not a generation), 80286, 80386, 80486 are not the names of an architecture, even versions, only the processor model number. And whether IA-32 is an open architecture, I've no ideas. All the x86 clone processors are cloning the Intel products for its specification, or merely instruction set. But there were two 64-bit extensions to IA-32, AMD64 and IA-32e, even though the latter never released or identified, leaving AMD64 the only 64-bit extension today on market. Maybe there won't be other variety of 64-bit extension of IA-32 in the future, but differentiate IA-32 and AMD64 might make readers more easily to comprehend the fact. But what does AMD64 really refer to? The Long Mode part or the whole part? I won't think manufacturers could give a clear answer to it, but I prefer the former. Anyway, thank you, and Merry Christmas! Password Saeba Ryo (talk) 09:07, 25 December 2014 (UTC)

Nobody's saying that 8086, 80186, 80286, etc. are the names of an architecture; the name being used is just "x86".

We do differentiate IA-32 and x86-64; they even have separate Wikipedia pages.

AMD64 refers both to long mode and legacy mode; Read The Fine Manual. And Intel64 refers to real mode, protected mode, SMM mode, compatibility mode, and 64-bit mode, as The Other Fine Manual says. You may prefer that AMD64 only refer to long mode (or that Intel64 only refer to 64-bit mode), but AMD and Intel prefer the latter, and they're the ones who actually define the architectures, so they win. Guy Harris (talk) 10:00, 25 December 2014 (UTC)

Anyway, for the latter reference you provide, the title is Intel 64 and IA-32 Architectures Software Developer's Manual. OK, it does not matter who win, who lose, the most important is that this is another page on Wikipedia.org. Password Saeba Ryo (talk) 10:28, 25 December 2014 (UTC)

That's fine, Wikipedia also covers them separately through IA-32 and x86-64 articles. — Dsimic (talk | contribs) 11:22, 25 December 2014 (UTC)

If some words like "Generally, x86 is a family of backward compatible instruction sets and their realisations (processors), first found on Intel processor 8086. ... But narrowly or specifically, people use it to refer to IA-32 instruction set and processors, or 32-bit part only ...i386, i486, i586 and i686 are used to refer to instruction sets which 80386, 80486, Pentium and Pentium Pro use, including their clones..." might help improve the main article... Password Saeba Ryo (talk) 01:11, 27 December 2014 (UTC)

It might be better to leave the IA-32 relationship description to the x86 § Extensions of word size section, while the lead section already has a hatnote that sums it up briefly. — Dsimic (talk | contribs) 07:22, 27 December 2014 (UTC)

Recent changes to the big table

I have severe doubts about at least some of these changes, particularly denoting the Intel Xeon Phi and the Transmeta chips as "Foreigners" and putting them at the end, out of chrono order. Jeh (talk) 09:10, 13 January 2015 (UTC)

pings: @Guy Harris: @Gegigie: (please add anyone else whom you think might be interested)

So what exactly do the generations represent? They seem to represent time slices, mainly - for example, "mainline" Intel processors and Atoms are grouped together in the "8th/9th generation" - so the "foreigners" presumably should be grouped with other processors available at the same time. (And there are multiple generations of Atom; Silvermont appears to be a different microarchitecture from Bonnell, as the former is out-of-order while the latter is in-order.)

And what makes an "nth/(n+1)st" generation different from both the nth generation and the (n+1)st generation? Why is it not a generation of its own? Guy Harris (talk) 12:43, 13 January 2015 (UTC)

That's part of why I'm asking. Is there a RS somewhere for what this table calls "generations"? To say nothing of the term "Foreigners"? Jeh (talk) 12:49, 13 January 2015 (UTC)

I just want to make corrections and put the proper thing to the proper place. Reasons list below:

• 1. Sort Transmeta, Intel Xeon Phi (Larrabee) and Intel Itanium into the Foreigners at the bottom

Phi is not a traditional x86 processors, no popular x86 operating systems is compatible with it.

Transmeta is not x86 processor; Morph emulator firmed on mainboard is the tie binding it (64-bit or 128-bit VLIW engine) to the x86 (32-bit CISC processor).

There is IA-32 engine on the Itanium processors.

For their special natures, I re-arranged them onto the bottom.

• 2. The Group of 5th/6th and K6/2/III

There should never be the half-generations, but clones make it have to be possible. The reason is x86 clone processors are not always creating a new generation. Processors in the 5th/6th column are all discrete microarchitecture design, resembling Intel Pentium Pro, but not fully overtake it. Even though VIA C3 could work on Pentium II/III platform, but it is not a superscalar and out-of-order scheduler design, lack of PAE support, so I sorted it onto this group. K6 is different, even though lacks of PAE support, and works on enhanced Pentium platform, but through most aspects (superscalar, RISC core, out-of-order, multi-level caches... ) enable it onto the group of 6th generation.

• 3. The 6th/7th Generations

The prominent feature of the 7th generation x86 processor is the double (AMD K7) or quad pumped(Pentium 4, VIA C7) FSB at implementation level rather than architecture or microarchitecture level, so Pentium M (6th), VIA C7(5th/6th) and Intel Core(6th) are just right for it.

• 4. 8th/9th vs 9th

The criterion to class the 8th generation x86 processors is 64-bit general computing and/or multi-core; the 9th is the technique of fusing or integrating GPU onto CPU processors. AMD LIano (8th core plus GPU), early versions of core i3/i5/i7 (GPU on chip not on die) are suitable to 8th/9th. Atom and Bobcat are the first trying to integrate GPU to simple cores. Atom should have a table list of it generations.

• 5. Bound by Timeline vs Fact

Keep consistency of Linear/physical address space, the order-disruption could not be avoided within generations.

Gegigie (talk) 14:48, 13 January 2015 (UTC)

Unless there are reliable sources for these "generations" they're original research. We'll have to delete that column. And that removes your objection to keeping the table strictly in chrono order.

I don't think that objection is well-founded anyway. Your arguments for putting Transmeta, Xeon Phi, and Itanium in a "foreigners" class whose name you just made up are specious. If they belong here at all, then they belong in the table in chrono sequence. Personally I would exclude Itanium; just because it can run x86 code doesn't make it part of the x86 architecture line of development. That Transmeta "merely emulates" x86 is really no different from all microprogrammed x86 implementations; the physical arrangement is just different. And Xeon Phi is still x86 architecture. That it has a bus architecture and other arrangements intended for very parallel machines/HPC, and so won't run mainstream OSs, does not mean it is NOT part of the x86 family tree. A small offshoot branch, perhaps, but not a bastard. Jeh (talk) 00:30, 14 January 2015 (UTC)

my revision is gone! Gegigie (talk) 04:19, 14 January 2015 (UTC)

Well... that was an extreme reaction. Virtually everything I (and most people) write on talk pages should be read as if every sentence includes "In my opinion"—it would be tedious to write it that way, but that's my intent. I wanted a discussion, not a surrender! Jeh (talk) 04:54, 14 January 2015 (UTC)

ok, my revision is back with only respect for jeh's comment! Gegigie (talk) 05:07, 14 January 2015 (UTC)

Hello! The "foreigners" class is highly confusing; as Jeh already explained, those processors are part of the x86 architecture, and it might be the best to list them chronologically. Having additional notes for them would be just fine, though. — Dsimic (talk | contribs) 05:35, 19 January 2015 (UTC)

Yes, you are right. "foreigners" is not a perfect term to point them out. But I think to sort those three kinds of processors out is reasonable. Would you please find another even more proper term for them? Computerfaner (talk) 11:42, 23 January 2015 (UTC)

Hm, maybe "related designs"? However, I still find that simply listing them chronologically, with additional notes, would be the best option. — Dsimic (talk | contribs) 11:49, 23 January 2015 (UTC)

Thank you for your reply. But please let me say if you sort Transmeta into them by timeline, then to what generation it should belong? Well, the criterion. You are pleased to turn it back or improve it. Please forgive my words on you before. Computerfaner (talk) 11:59, 23 January 2015 (UTC)

You're welcome. AFAIK, Transmeta CPUs were virtually identical to Pentium 4, so they should be placed wherever Pentium 4 is slotted. — Dsimic (talk | contribs) 12:11, 23 January 2015 (UTC)

I repeat a question I raised above: Is there a reliable source for all of these "generation" designations? If not, that column will have to be deleted as OR. And this will nicely eliminate the question of "to what generation does it belong?" Jeh (talk) 12:29, 23 January 2015 (UTC)

Hm, http://www.cpu-world.com/CPUs/CPU.html and http://www.rcollins.org/computalk/help.htm provide some information on different x86 processor generations. — Dsimic (talk | contribs) 12:39, 23 January 2015 (UTC)

Neither of those look like particularly RSs to me. The first does not use the same numbers as in this table, does not have nearly as many fine divisions, and does not put AMD, Intel, and others into the same scale. The second does not identify all of the generations by number, what "numbers" it does offer are different from the first source and also different from the table, and it basically ignores AMD. Even if we could consider them RSs neither of these back up the table (or each other).

This question was raised over seven years ago (see the second section in this talk page). Time to find RSs or delete the column. Jeh (talk) 12:48, 23 January 2015 (UTC)

Linear address space nonsense

No, the 80286 does not have a "30-bit virtual" address space, nor do the 80386 through Pentium 4 have "46-bit virtual". The fact that 14 bits from the segment register participate in the calculation of the linear address does not mean you have register_size + 14 bits of "virtual address". If that were true, then the 80386, for example, could address 2⁴⁶ different bytes, and that's clearly nonsense.

Yes, a total 46 different bits can be specified by the programmer (32 of them in the displacement and 14 in the segment selector), but there is a many-to-fewer mapping between the various possible combinations of those 46 bits and the 32 bits of the resulting linear address. It's not as if the segment register bits get appended to the displacement! Jeh (talk) 09:16, 13 January 2015 (UTC)

The 80386 could work in an address space larger than a single 2^32-byte address space, using segmented addresses. It might take a lot of "segment not present" faults doing so, however, as those segments all have to get stuffed into a 2^32-byte linear address space, just as an 80386 would work, without using segmented addresses, in a 2^32-byte address space on a machine with, for example, 1MiB of main memory, but take a lot of page faults doing so.

This is a bit different from other segmented systems, where there's no requirement to stuff segments into a fixed-size virtual address space on top of stuffing the relevant pages into a possibly-limited physical address space, so the OS memory management could would have to do more work, and code running in a large segmented address space might get slowed down by all the "segment not present" faults. You'd also have to use two instructions to load pointers, loading the segment portion of the pointer into a segment register with one instruction and loading the offset with another instruction, and the programmer or the compiler would have to deal with a limited number of segment registers.

And, as with other segmented systems, it'd be difficult to manage single objects, such as large arrays, bigger than the maximum segment size.

Perhaps it's better to speak of the 80286 segmented address space as 14+16 bits, and the IA-32 segmented address space as 14+32 bits, to indicate that they're not linear address spaces. Guy Harris (talk) 12:29, 13 January 2015 (UTC)

THe above is an incorrect interpretation in my opinion. You are not describing an address space larger than a single 2^32-byte address space, you're describing several. Or many. x86 with page table translation can also have an essentially unlimited number of 32-bit address spaces (implemented as processes in all OSs I'm familiar with), each defined by a different page table tree, with the root pointed to by CR3. But we don't count those when we say it has a 32-bit address space. Because only one 32-bit address space exists at any one time.

My position is that if the 14-bit segment selector value is not appended to the 16- or 32-bit displacement—and we both know it isn't—then we can't say we have 30- or 46-bit virtual addresses.

To do so flies in the face of the usual interpretation of "virtual address space", and massively confuses anyone not familiar with how segmenting works. We just can't put this one sort of "46-bit virtual" claim and the "64-bit" claim for x64 in the same table without a lot more explanation.

While we're talking about this, what's with the bolded numbers in that column? There's no rhyme or reason to them.

Also, the "64-bit" virtual ones for the x64 processors needs to have "48 bits implemented" appended. Jeh (talk) 12:48, 13 January 2015 (UTC)

Are you saying that there is no such thing as a segmented address space, because, with segmentation, you don't have a single address space, you have multiple address spaces, one per segment?

This isn't like address space switching, as multiple segments can exist at one time. You could have at least 6 segments with descriptors loaded in the segment register, and more segments in the GDT or LDT, and if you can manage to pack them all in the 4 GiB linear address space, they're all even accessible at the same time. Guy Harris (talk) 13:18, 13 January 2015 (UTC)

I'm not saying that switching segments, or even redefining segments, is the same as changing CR3 to point to a new PD. I'm saying that these are similar enough notions that if we don't count the bits in CR3 as part of the VA size with paging enabled, then we can't count the bits in the segment register when paging is disabled.

Think about this: On the 16-bit CPUs, the input to the linear address calculation is a 16-bit displacement added to an effective 20 bit segment base address. That produces 20 bits of linear address. Not 36, and not 30. It is incorrect and misleading that this equates to a "30 bit virtual address" just because the SR provides 14 bits. "30 bit virtual address" says that you have 2^30 possible addresses, and you just don't.

Now in 386 protected mode, the SD provides effectively 32 bits, and the displacement provides 32 bits... added together, for 32 bits out. If they had chosen to have a different number of possible SDs, hence a different number of bits in the SR, those numbers would not change. The size of the segment register is irrelevant to the number of bits in the virtual address. Jeh (talk) 00:12, 14 January 2015 (UTC)

Sorry, I'm not convinced that changing CR3 is particularly similar at all to loading a different segment descriptor into a segment register. For one thing, changing CR3 is a privileged operation but loading a segment descriptor isn't.

And, on an 80286, a segmented virtual address of 00:FF00 is not the same as a segmented virtual address of 01:FF00, which is not the same as a segmented virtual address of 02:FF00, just as a segmented address of 00:FF00 is not the same as a segmented virtual address of 00:FF01. So, given that, why don't you have 2^(14+16) possible different segmented virtual addresses? You might not be able to have all those segmented virtual addresses mapped to physical addresses at the same time, but that's no different from not being able, on a 16 MiB system with a 2^32-bit flat virtual address space, to have all of those flat virtual addresses mapped to physical addresses at the same time.

The same applies to IA-32 processors, except that the segmented virtual addresses are mapped to a flat paged virtual address space rather than to a flat physical address space; segments can be swapped in and out of the linear address space, just as they can be swapped in and out of physical memory on a 286. This is different from, for example, the Honeywell 6180, where a 12-bit segment number is used to look up an entry in a top-level page table, and the remaining 18 bits of the virtual address are used to look up the an entry in that table and in lower level page tables, so that the 12+18-bit segmented virtual address directly gets translated to a physical address, without going through an intermediate paged linear address space. (The IA-32 scheme might work better with small segments, as it allows multiple small segments per page; the Honeywell 6180 scheme was, not surprisingly, better oriented towards Multics, in which segments corresponded to files.) However, that doesn't render the segmented address any less virtual.

The problem is that an IA-32 processor has two different types of virtual address - segmented virtual addresses that get mapped to linear addresses and unsegmented virtual addresses in the linear address space that get mapped to physical addresses. The former type of virtual addresses are (14+32)-bit addresses, the latter type are 32-bit addresses. The 80286 has only one type of virtual address, a (14+16)-bit segmented virtual address, that gets mapped directly to a physical address.

What matters, if you really have virtual addresses (unlike what you have on the 8086/8088 and 80186/80188) is the number of bits in, not the number of bits out. An 80386SX has only 24 physical address bits out, but it still supports a 32-bit linear virtual address space and a (14+32)-bit segmented address space, just like a 32-bit-physical-address 80386 does. Guy Harris (talk) 01:18, 14 January 2015 (UTC)

Because 01:FF00 is the same as 00:FF10. You are correct that what matters is the number of bits in. But there are only 20 bits in. Jeh (talk) 04:42, 14 January 2015 (UTC)

On an 8086/8088, an 80186/80188, or a later processor when running in real mode, they are the same.

However, when running in protected mode on an 80286 or later, which is what we're talking about when we talk about virtual addresses on x86, they are most definitely not the same; the value loaded into the segment register by the program is not shifted and added to the offset within the segment. Instead, when the value is loaded, that value is used to look up a segment descriptor in the GDT or LDT, and data from the descriptor is loaded into the "invisible" part of the segment register. When an access is attempted, the offset is checked against the length in the segment descriptor and, if it's within the length, and the descriptor's permissions allow the access, the base from the descriptor is added to the offset to give the physical address on an 80286 or a later processor if paging is turned off or to give the linear address if paging is turned on. See, for example, chapter 6 "Memory Management and Virtual Addressing" of the iAPX 286 Programmer's Reference. Guy Harris (talk) 09:25, 14 January 2015 (UTC)

I know all that. See my reply to Gegigie below. I was addressing your example and your question, which concerned real mode.

Your description of protected mode is of course correct. The problem is in your conclusion that just because 14 bits come out of the SR, we can add that number to the 32-bit displacement and conclude that there is such a thing as a 46-bit virtual address. The bits from the segment register are not bits of address, they are bits of an index value that is used to look up a segment descriptor, which in turn contains a 32-bit base address, which is then added to the 32-bit displacement generated by the operand. The result is a 32-bit address. Not 64, and not 46. There is no such thing as "46 address bits", certainly not a "46-bit address", anywhere in the sequence. An index value is not an address, nor part of one. Jeh (talk) 10:06, 14 January 2015 (UTC)

My example wasn't intended to concern real mode; perhaps I used the wrong syntax for a protected-mode segmented address, making it look as if I were talking about real mode. When I speak of "segmentation" and "segmented addresses", I'm not referring to real-mode "segmentation", I'm referring to protected-mode segmentation.

And I'm afraid we'll always disagree on whether a segment number is part of an address. I agree with the Multics hardware and software developers, and with Intel, and consider them to be part of an address. See, for example, "System Design of a Computer for Time Sharing Applications", which says

A segment can now be identified by an ordinal number which locates its descriptor relative to the base of the descriptor segment. This number is known as the segment number. The address of a location in memory is specified in terms of a segment number and a location within that segment. In the 645 both quantities are expressed as 18 bit numbers. During all addressing in the 645 both parts are necessary except under very unusual circumstances. Both parts are usually supplied explicitly. In some cases they are implied by certain conditions of the machine.

and the Intel 80286 manual, which, for example, shows "32-bit virtual address" in figure 6-1, showing it with a 16-bit "segment selector" and a 16-bit "segment offset".

Segmented addresses aren't linear addresses, so speaking of the GE 645 as having 36-bit addressing and the 80286 as having 30-bit addressing would be misleading; it would be better to say the GE 645 had (18+18)-bit virtual addressing and that the 80286 had (14+16)-bit virtual addressing.

So I guess we'll just have to agree to disagree on this one; perhaps having programmed for Multics, I'm used to the notion of segmented addressing, with pointers including a segment number (which they did in Multics PL/I, and "far" pointers did in C compilers for x86), so it doesn't bother me to think of the GE 645 having (18+18)-bit addressing or the 80286, in protected mode, having (14+16)-bit addressing. Guy Harris (talk) 19:44, 14 January 2015 (UTC)

Ok. Can we at least agree that a claim of "46 bits" implies being able to address 2^46 different locations all at the same time, and that is flatly not the case, and therefore the table's presentation of this information should be changed to be more descriptive of what is actually going on? Jeh (talk) 22:32, 14 January 2015 (UTC)

That depends on what you mean by "all at the same time". Using segmentation on an IA-32 processor would allow you to have a pointer variable that could point to 2^46 different virtual memory locations; however, not all of those locations could be present, so some references to those pointers might cause a "segment not present" fault, which the OS would have to resolve by removing some other segment from the linear address space and moving that segment into the linear address space.

The real problem with saying "46 bits" is that it could be read as indicating that there's a 46-bit linear address space, allowing, for example, a single array to be (almost) 2^46 bytes long. That's not the case - segmented addresses are, as indicated, two-dimensional.

So the right way to say it is not "46-bit" but "14+32-bit" (or "(14+32)-bit"), and to clearly indicate that those refer to segmented addresses. I updated the page to do so just now, right before checking the talk page. Guy Harris (talk) 00:10, 15 January 2015 (UTC)

Most important of all, x86 (x86-64 is) is not purely a NT or UNIX(-like) flavour processor. It was first designed for IBM PC, DOS and OS/2 ( rather than XENIX or later NT) were the very initial motivation for its development from 16-bit real eventually to 32-bit protected. The linear address space is the feature of instruction set architecture (implemented or unimplemented), the physical address space or PAE is only a feature of implementations (must be implemented). So they both are necessary and important. Virtual address is important for programming under OSes rather than UNIX-like or NT. SD + SA is a good suggestion. Gegigie (talk) 15:07, 13 January 2015 (UTC)

My objections have nothing to do with any particular operating system or CPU architecture affinities therefor. Jeh (talk) 00:12, 14 January 2015 (UTC)

my revision is gone! Gegigie (talk) 04:20, 14 January 2015 (UTC) I bring it back for jeh's comments.

@Jeh's negative reply, there is no segmentation on NT and most Unix-like operating systems, so programmers of that kind do not need to care about the existence of virtual address for segmented memory system. For IA-32 architecture, under segmented system, 46-bit address space could be swapped in and out to disk(s), resulting in a total 64TiB virtual memory space. Virtual Memory is a term in operating system, and no CPU architecture is designed without consideration of operating system which would run on it. Enough! Gegigie (talk) 05:22, 14 January 2015 (UTC)

"For IA-32 architecture, under segmented system, 46-bit address space could be swapped in and out to disk(s)"

The only way to get to 46 bits is to count 14 bits from the segment register. But those are not bits of address. They are used to select one of two descriptor tables (global vs. local) and index into the selected table to find a segment descriptor, from which is read a 32-bit segment base address. Which is then added to the 32-bit displacement from the instruction. But you do not get 64 bits when you add two 32-bit numbers together, you get 33... except that carry to the 33rd bit isn't allowed in this case, so you still have only 32.

There is just no way to say that this results in a "46-bit virtual address space". Just because the SR provides 14 bits to the mechanism doesn't mean it provides 14 bits of address. Counting this as part of the size of the address is absurd. Jeh (talk) 05:31, 14 January 2015 (UTC)

Sorry for my tone. I do apologize! You are right, but please consider the following situation:

MOV ES:[2000 H], AL

OK, I need more to learn. I've realised that I made some mistakes in my minor revision. Please improve that table for me and for someone like me as a beginner. I am sorry, but wish you all have a good day! Gegigie (talk) 05:48, 14 January 2015 (UTC)

Your tone is fine. Again, please don't run off. We're all here to learn as well as to write.

A minor point: There isn't quite no segmentation on NT. On x86-32, you can't enable paging without having segmenting enabled. Practically all of the SDs are loaded with base address 0 and size 4 GiB, but segmenting isn't turned off. It can't be. There are two sets of segment descriptors in common use, one with PL=3 and the other with PL=0. Changing between user and kernel mode includes loading the SDs with the appropriate values to select the right set of SDs.

In addition, the FS and GS segments exist in a sort of "vestigial" form. They are used to "point to" some OS data structures, the Thread Information Block and the Processor Control Region. Thus in kernel mode, 0[GS] refers to the first byte of the PCR for the current processor.

As it says in the Intel64 System Programming Guide, "These [FS and GS] segment registers (which hold the segment base) can be used as an additional base registers in linear address calculations. They facilitate addressing local data and certain operating system data structures.” These "vestigial" segments were left in the architecture by AMD's designers because NT, at least, used them that way on x86, and AMD did ask for input from various OS kernel teams. Jeh (talk) 06:19, 14 January 2015 (UTC)

Yes, those 14 bits from the segment register are bits of address according to Intel. See, for example, the iAPX 286 Programmer's Reference, chapter 6, as per the above. What you get on the 286, or on a later processor when paging is disabled, when you add the segment base to the offset within the segment is a physical address.

On a processor that supports segmentation but not paging (such as an 80286), virtual addresses are different from physical addresses, so the number of bits you get when you add the segment base to the offset within the segment is irrelevant to the size of virtual addresses on the machine.

On a processor that supports segmentation and paging on what I remember being the GE 645/Honeywell 6180/etc.-style, the segment descriptor for a paged segment points to the top-level page table for the segment, and the offset within the segment is used to look up a page table entry in that page table. Virtual addresses are again different from physical addresses, so the number of bits you get when you walk the page table given the offset within the segment is again irrelevant to the size of virtual addresses on the machine.

On a processor that supports segmentation and paging IA-32-style, there are two types of virtual addresses, segmented virtual addresses and linear virtual addresses. The segmentation hardware generates a linear virtual address rather than a physical address, and the linear virtual address is run through the page table. The number of bits you get when you add the segment base to the offset within the segment is the size of linear virtual addresses on the machine, which is irrelevant to the size of segmented virtual addresses on the machine, and the number of bits you get when you walk the page table with a linear virtual address, i.e. the size of a physical address, is irrelevant to the sizes of either of the two types of virtual addresses. Guy Harris (talk) 09:50, 14 January 2015 (UTC)

Sorry for not responding sooner. My available Wiki-energy has been consumed recently with other things.

I see your point. PDP-11 also used similar nomenclature. Perhaps the table needs a third column, one for "segment table index" bits and one for "offset in segment" bits. And maybe another one for "number of segments" (six at most, yes?). Jeh (talk) 21:25, 23 January 2015 (UTC)

No, 2^14 segments. You can only point to 4 at any given instant prior to IA-32 and 6 at a time in IA-32, so if you're working with more segments than that, you'll need to spend some instructions loading different descriptors into the ES/FS/GS registers ("far call" instructions will take care of that for multiple code segments and CS). So it's more "number of segment registers" than "number of segments" - you can have more objects pointed to than general registers, you just have to move pointers into and out of registers, and the same applies to segments; in order to load a far pointer, you need to have both a segment register and a regular register free, one to hold the segment index (and descriptor) and one to hold the offset-within-segment. Guy Harris (talk) 21:51, 23 January 2015 (UTC)

I know that. I was referring to the "at any given instant" point. The 2^14 is already covered by the number of segment table index bits. What do you think about putting "segment table index bits" and "offset in segment bits" into separate columns? Jeh (talk) 22:43, 23 January 2015 (UTC)

I'd put the number of segment registers into a "number of segment registers" column - or maybe there should be a column giving the registers, both "regular" and segment.

Or perhaps we should just give, for IA-32 and x86-64 processors, the instruction set, and let that indicate the number of GPRs and segment registers, giving details only for the 8086/8088, 80186/80188, and 80286, rather than having a ton of "As above" items.

"offset in segment bits" is the same as "linear address bits", i.e. 16 pre-IA-32 and 32 for IA-32. (Segmentation is N/A for x86-64.) Guy Harris (talk) 22:56, 23 January 2015 (UTC)

Minor Change I've Made

I've changed Chronology to Generations. Computerfaner (talk) 11:21, 23 January 2015 (UTC)

8088 should be in the lede.

The lede should mention the 8088, given that it mentions the 8080, and the topic is x86. and why is this article locked? 68.173.49.156 (talk) 22:20, 12 February 2015 (UTC)

I added a brief mention of the 8088. It's locked because of "persistent sock-puppetry"; this edit protected it. Guy Harris (talk) 22:57, 12 February 2015 (UTC)

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.