Talk:Comparison of instruction set architectures

Scope

The recent addition of a section about microarchitectures raises questions regarding the scope of this article. Just what does "CPU architecture" refer to? It seems that everyone has their own ideas as to what it means. The term is extremely vague. The topic, however, is not. Instruction set architecture (what one half of the article is about) is distinct from microarchitecture. Either the scope is ISA or microarchitecture, it cannot be both. Since this article started as one on ISAs, I suggest that the scope remain that. For clarification, I also suggest that this article be renamed to "Comparison of instruction set architectures" or similar. The microarchitecture section should be removed. I suggest it not be moved to its own article since the section is not particularly useful as it is oversimplified, and because it covers a topic that is vast and better covered in detailed articles. Rilak (talk) 04:27, 21 December 2009 (UTC)

I agree. 208.118.18.233 (talk) 05:34, 27 November 2010 (UTC)

So do I. I added a section to suggest the rename. Guy Harris (talk) 08:36, 3 December 2013 (UTC)

Rename done. There's now a section below in which to discuss whether to move the microarchitecture section to another page or just to get rid of it. Guy Harris (talk) 21:28, 11 December 2013 (UTC)

"Open" and "Royalty-free"

Exactly what do these mean? I'm kind of guessing that "Open" means "documented" and that "Royalty-free" means "unpatented". If so, then those would be the terms to use.

How is it that PowerPC supposedly "Open" but Alpha supposedly is not? Both have documented instruction sets. I suspect you'd be more likely to get sued for implementing PowerPC than Alpha, since PowerPC lives on.

Right now x86 gets a "no" for both, yet clearly is it documented and the original patents have expired. There is now an unlicenced x86 clone made by RDC, and there is nothing Intel can do about it.

The VAX patents must have expired over a decade ago.

MIPS is royalty-free now. The patent related to unaligned load/store has expired.

208.118.18.233 (talk) 05:34, 27 November 2010 (UTC)

Number of registers in "Instruction sets" table

In the table why is ARMv8-A listed as having 31 registers and MIPS as having 32 registers? Both of them have a hardwired-zero register and seperate PC register. In fact MIPS don't even have seperate dedicated SP and may be considered having less real general-purpose registers than ARMv8. Except for that point, the register set is almost the same. x86 also includes SP in its register list, some of the registers are not general-purpose in some instructions but is listed as an 8-registers architecture in the table too. I think the registers column should show the number of registers that can be encoded in the instruction as well as real general purpose registers. Seperate SP/PC/Zero, if any, should also be shown.

Vip17 (talk) 02:04, 14 November 2013 (UTC)

From the article:

"However, often one "register" is hardwired to zero, so it's not usable as a register, and is not counted below."

I object to this. And I would also point out that it's been done inconsistently in the table. More critically: If the manufacturer says the number of GPRs is 32, but we say 31 "because one is the zero register and another is the program counter, which is not really general purpose," that's original research unless you can find reliable sources to back it up.

I agree with Vip17: The registers column should simply show the number of registers that can be encoded in the instruction (which, for x86, excludes the instruction pointer). A notation such as "includes zero and PC registers" can appear where necessary. Jeh (talk) 18:37, 20 May 2014 (UTC)

I put the above quote in; 'often one "register" is hardwired to zero, so it's not usable as a register' is a fact (in the accepted sense of a processor register as "memory location") and 'and is not counted below' was true at least for ARMv8-A. And MIPS (it's listed as 31). Please fix if you find other errors. For ARMv8-A they do say 31 I believe. I recall having read ARM's manual and lots of sources saying that. It's page says "31x 64-bit integer registers[1] plus PC and SP, ELR, SPSR for exception levels". What is fair here? We could say 33 (or 35?) counting PC and SP.. They are registers.. I believe including the PC in the "general" register set of older ARM's is very unusual, making the count 16 (and unfair to x86 and others..). Really pre-ARMv8-A could justifiably say 15 registers (or even 14, but then again R14, the SP, IS general purpose..), if only counting general purpose registers, but sources usually say 16.. "should simply show the number of registers that can be encoded in the instruction" to mean eg. 32 for ARMv8-A would be OR.. The "instructions" (in general) can encode 32 possibilities, 31 there of are registers, one isn't, saying they are all registers is not supported by facts or sources. What do we really want? Show the most useful number? If MIPS (or any other manufacturer) has ever said 32 "registers" including zero-hardwired, we have a dilemma, but not really as I'm sure the hardwired-zero is documented. In this case the WP:PRIMARY source - their technical documents decide.

[One possible "justification" for counting hard-wired zero is that zero is much used(?) and in that case it saves you one register.. But either way we go I we would want consistent as possible.] comp.arch (talk) 20:13, 20 May 2014 (UTC)

I don't believe "fairness" or "most useful" is a valid concern for a WP article. We go with what the manufacturer's documentation says, and add notes to clarify. Note that the Alpha claims (claimed) 32 GPRs, including both zero and PC. Similarly, VAX had 16 GPRs, including PC. In both of these cases the PC can be specified in the instruction coding (this is used for data references in position-independent code). Jeh (talk) 21:10, 20 May 2014 (UTC)

I'd vote for giving the number of registers that the instructions can address, with special notes for zero registers, PC, registers used implicitly as stack pointers and thus less useful or not useful as fully GPRs, etc..

(A side note - PC wasn't a GPR on Alpha, but R31, an always-zero register, was. I don't have any spec for ELF-on-Alpha, but I suspect PIC for data references is done with the same trick used on some other architectures, wherein the prologue to a PIC routine makes a procedure call to the instruction immediately following it and, if that instruction pushes the PC onto the stack, pops it into a register, and the register containing that PC value is now used as an index register.) Guy Harris (talk) 23:11, 20 May 2014 (UTC)

Sure it is a valid concern, in this case, the table is a "mini-list-article", and I believe comparing its entries should be fair. That would be "most useful" to the reader. We can not have different standard for each entry in the table. How do you want to list SPARC and Alpha in this article? 31 and 32 (because manufacturers (possibly) count the same situation differently)? Or the appropriate 31 and 31? The table in processor register is also wrong. Only SPARC has a note "Global register 0 is hardwired to 0". And note form that article: "General purpose registers (GPRs) can store both data and addresses". Hard-wired zero can only "store" the data zero or the address zero - hardly very gerneral.. and not a register. [Changing heading in the table here to general purpose register as it doesn't include floating-point..] comp.arch (talk) 10:33, 21 May 2014 (UTC)

You cannot, by Wikipedia's rules, list a number of registers other than what the "horse's mouth" documentation states. It is fine to append to that number "one of them is a zero register". But you can't subtract one from the number the doc states and put that in the table. That is exactly a case of "original synthesis". It would be fine in an article or book published under your own name, of course. It doesn't matter if you consider the zero register "hardly a register" or not; it's addressed as one. Jeh (talk) 12:06, 21 May 2014 (UTC)

Can you point at the examples in the list you would like changed and sources that say otherwise? Or even one? You seem to be missing my point, I don't think the "horse's mouth" will say that, eg. R31 in the Alpha is a processor register, GPR or not. I would like a a source before changing anything that counts hard-wired zero out. Then I can find a more reliable source from the "horse's mouth" saying it is not a real register. I can't be bothered looking up sources for every architecture with facts I believe to be true. And you didn't answer what you would do with the supposed SPARC/Alpha dilemma (I've changed Alpha to 31). comp.arch (talk) 13:57, 21 May 2014 (UTC)

My Alpha architecture book has gone missing and I have to catch a plane in a few hours. But I'll come back to this. In the meantime, WP:V requires that everything you put on Wikipedia be verifiable. It matters not that you believe it to be true. If you want to write just based on what you believe to be true, and "can't be bothered" to find references, then you probably need to review WP:V, WP:RS, etc., and consider whether you really would prefer to be writing on a blog where you're not going to be required to provide sources.

I don't know SPARC well enough to address that point, but I do know that the number for Alpha should say 32, with a note that one of them is the zero register. Because, unless my memory is very faulty, that's what the book says. I'll be able to quote you a page number later. The counts for other architectures, whether they count the zero register or not, are irrelevant. Jeh (talk) 15:19, 21 May 2014 (UTC)

I found your Alpha book. It says, in section 3.1.2 "Integer Registers":

There are 32 integer registers (R0 through R31), each 64 bits wide.

Register R31 is assigned special meaning by the Alpha architecture. When R31 is specified as a register source operand, a zero-valued operand is supplied.

As for SPARC, the SPARC V8 manual, for the final version of 32-bit SPARC, says, in section 4.1 "IU r Registers":

An implementation of the IU may contain from 40 to 520 general-purpose 32-bit r registers. They are partitioned into 8 global registers, plus an implementation-dependent number of 16-register sets. A register set is further partitioned into 8 in registers and 8 local registers.

and, after that, under "Windowed r Registers":

At a given time, an instruction can access the 8 globals and a 24-register window into the r registers. A register window comprises the 8 in and 8 local registers of a particular register set, together with the 8 in registers of an adjacent register set, which are addressable from the current window as out registers. See Figure 4-1.

Later, under "Special r Registers", it says:

The utilization of four r registers is fixed, in whole or in part, by the architecture:

* If r[0] is addressed as a source operand (rs1 = 0 or rs2 = 0, or rd = 0 for a Store) the constant value 0 is read. When r[0] is used as a destination operand (rd = 0, excepting Stores), the data written is discarded (no r register is modified).

* The CALL instruction writes its own address into register r[15] (out register 7).

* When a trap occurs, the program counters PC and nPC are copied into registers r[17] and r[18] (local registers 1 and 2) of the trap’s new register window.

and the SPARC V9 manual, for 64-bit SPARC, also, in section 5.1 "Nonprivileged Registers", speaks of 8 global registers (including the wired-to-zero g0) as well as the register windows.

As for MIPS, the MIPS Architectures page on the Imagination Technologies Web site has "MIPS32 Architecture" and "MIPS64 Architecture" links, from which you can, if you've registered (for free) on the site, you can download documentation. The "Introduction to the MIPS32 Architecture" section of the MIPS32 manual says, in section 2.8.4 "CPU Registers", that it has 32 GPRs, of which r0 is wired to 0 and r31 is used as an implicit destination for subroutine call instructions but is otherwise usable as a GPR. The MIPS64 manual says the same thing.

So I'd say what comes from the horse's mouth is "we count hardwired-to-zero registers as GPRs, and note that they're special". Guy Harris (talk) 17:17, 21 May 2014 (UTC)

Thanks for providing those sources Harris. There is nothing there contradicting that one "register" isn't "real" GPR: 'The contents of a register can be “read” or “written” very quickly' [1] [2]. I can be bothered to look up sources (more on that later, running late). What I meant is that those sources will say that hard-wired zero isn't a "real" register as they did or if not I would find those that do. Mashey puts register in quotes for a reason: 'implemented to act as a "register" that delivers zeroes when read, and ignores anything that is written' [3]

You have WP:V backwards. There doesn't have to be anything contradicting your claim that Alpha's R31 isn't a "real" register. You're the one making the claim, so you're the one who has to provide a source for it. You can't just make up an explanation or interpretation like that on Wikipedia. Dick Sites and Richard Witek (Alpha Co-architects) didn't put "register" in quotes when describing R31, so you can't either.

I find it highly amusing, not to mention telling, that after you wrote "I don't think the "horse's mouth" will say that, eg. R31 in the Alpha is a processor register, GPR or not, Guy Harris provided a quote that's in effect signed by the two principal designers of the Alpha architecture saying exactly that—and you seem so unmoved by it that you might as well never have read it. And I wonder just where you think you'll find a more reliable source for the Alpha. Wikibooks are most certainly not considered WP:RSs here. Nor are Usenet archives, for the same reason: They're self-published with no editorial oversight, no way to even verify authorship. (Re Mashey, he puts "register" in quotes in those posts once in 66 uses. Not a compelling argument for your side, even if we could use it as a source.)

Now, if you find a source regarding some other architecture (preferably one written by the architect) that says that don't regard the zero register as a "real" register, then that is fine for the table entries for that architecture. But you can't then willy-nilly apply that to all architectures, any more than I should apply the Alpha's counting method to all architectures.

In both cases, of course, there is nothing wrong with adding annotations explaining which "special" registers are included or excluded in the count. Maybe this is a common enough situation that the table needs an additional column following the register count, for exactly that information. Call the column "count includes or excludes" and have entries like "inc: R31 (zero)" for Alpha and "exc: Rwhatever (zero)" for those that do that.

If there are reliable secondary sources like well-regarded books on computer architecture design that say things like "although processor architecture descriptions often include a zero register in the register count, this isn't a real general-purpose register" then it is fine to cite that in the discussion that accompanies the table. But as for the table entries for Alpha and MIPS32/64, they're described by their inventors as having 32 GPRs, and that's what the table should say. I don't see how you can read WP:V and WP:RS and have any question about this. Jeh (talk) 19:59, 21 May 2014 (UTC)

After some reflection (before reading the last response), I agree to include zero hard-wired "register" in the count. Not because it is a register, but because it's commonly counted with them. I'll fix the article as I see fit and processor register. I just hope I do not have to argue for this view there.. comp.arch (talk) 20:54, 21 May 2014 (UTC)

So if there's an arch that's doc'd as having 31 registers plus the zero register, you would report this as 32? Sorry, but I don't think this is correct either. The counts in the table should reflect each processor's official documentation. And that you "propose to edit as you see fit" smacks of article WP:OWNersnip, which is a huge red flag here. Have you not understood WP:CONSENSUS? Jeh (talk) 21:44, 21 May 2014 (UTC)

Sorry, maybe a poor choice of words on my part. What I meant or should have said, I'll fix what I changed (eg. Alpha back to 32), as I feel a little responsible for the disagreement. I'm trying to reach a consensus. If there is anything in this article that I changed that there is no consensus on then I see it as my job to change it back. It is not my job to dig up information on architectures I'm not familiar with (and didn't change info on) that may not or may be correct already. I feel however that we should get a consensus what we write outside of the table and that it should clarify the table. I just changed so you didn't have to bother. Of course you can amend if you see fit. Note how this started: "In the table why is ARMv8-A listed as having 31 registers and MIPS as having 32 registers?" Not sure arch you are refering to (good to have actual examples), ARMv8-A? I see on the web that it has hardwired zero. I can't see it at the moment in the official documentation, but it has SP (and possibly it is zero when read?). Either way, yes, if it has 31 general and one special purpose, accessible as the other 31, then I think 32 is ok, as SP is also a register (not GPR). comp.arch (talk) 23:21, 21 May 2014 (UTC)

Ah, ok. Sorry for not assuming good faith. I don't believe I was the one who mentioned ARMv8-A. Jeh (talk) 23:44, 21 May 2014 (UTC)

Requested move 03 December 2013

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: Page moved. (non-admin closure) ^walk victor falk ^talk 10:38, 11 December 2013 (UTC)

---

Comparison of CPU architectures → Comparison of instruction set architectures – The first table is specifically discussing instruction set architectures, and the second table might belong elsewhere, as per the "Scope" section above. Guy Harris (talk) 08:34, 3 December 2013 (UTC)

Survey

Feel free to state your position on the renaming proposal by beginning a new line in this section with *'''Support''' or *'''Oppose''', then sign your comment with ~~~~. Since polling is not a substitute for discussion, please explain your reasons, taking into account Wikipedia's policy on article titles.

• Support -- DrSeehas (talk) 09:24, 3 December 2013 (UTC)
• Support -- Frap (talk) 11:50, 3 December 2013 (UTC)

Discussion

Any additional comments:

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Move comparison of microarchitectures to a new page, or delete it?

Now that this page has been retitled "Comparison of instruction set architectures", as per my suggestion, the table comparing microarchitectures should be moved to a separate page, as the microarchitectures used to implement various ISAs aren't relevant to the ISAs themselves. "Comparison of CPU microarchitectures" sounds to me as if it'd be an appropriate title. Guy Harris (talk) 21:26, 11 December 2013 (UTC)

Or, as per the "Scope" section above, just remove the table. Guy Harris (talk) 21:29, 11 December 2013 (UTC)

Move it to a new article. -- Frap (talk) 13:14, 23 December 2013 (UTC)

Moved. (If somebody thinks Comparison of CPU microarchitectures should be deleted, I won't oppose that; if somebody thinks it should be kept, I won't oppose that, either.) Guy Harris (talk) 09:15, 19 January 2014 (UTC)

Vector/accumulator register included (for some)

eSi-RISC includes 32 vector registers in count, when on one else(?) includes them (eg. x86-64). And 8 accumulators. AX in x86 is an accumulator.. Should we change the table? And floating point is not in this table (but is in Processor register). Only count similar register? Merge tables in some way? comp.arch (talk)

What's an "accumulator"? Is it an accumulator (computing)? If so, note that, as that article says, "Modern computer systems often have multiple general purpose registers that operate as accumulators, and the term is no longer as common as it once was.", and that the PDP-10, in fact, referred to its general-purpose registers as "accumulators". Are there many instructions in x86 that can only act on AX (presumably meaning "the lower 16 bits of EAX" on IA-32 and "the lower 16 bits of RAX" on x86-64), to the extent that it's worth noting, or can any of the GPRs be used in almost all contexts?

As for vector registers, I'd say that vector registers should be mentioned if, and only if, non-vector floating are mentioned, and this should apply to all architectures. Guy Harris (talk) 17:45, 27 May 2014 (UTC)

ARM architectures vs. ARM instruction set architectures

The "ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile" says, in A1.2 "Architecture Profiles":

The ARM architecture has evolved significantly since its introduction, and ARM continues to develop it. Eight major versions of the architecture have been defined to date, denoted by the version numbers 1 to 8. Of these, the first three versions are now obsolete.

and

The generic names AArch64 and AArch32 describe the 64-bit and 32-bit Execution states:

AArch64 Is the 64-bit Execution state, meaning addresses are held in 64-bit registers, and instructions in the base instruction set can use 64-bit registers for their processing. AArch64 state supports the A64 instruction set.

AArch32 Is the 32-bit Execution state, meaning addresses are held in 32-bit registers, and instructions in the base instruction sets use 32-bit registers for their processing. AArch32 state supports the T32 and A32 instruction sets.

and

ARM defines three architecture profiles:

A Application profile, described in this manual:

• Supports a Virtual Memory System Architecture (VMSA) based on a Memory Management Unit (MMU).

---Note---

An ARMv8-A implementation can be called an AArchv8-A implementation.

• Supports the A64, A32, and T32 instruction sets.

R Real-time profile:

• Supports a Protected Memory System Architecture (PMSA) based on a Memory Protection Unit (MPU).
• Supports the A32 and T32 instruction sets.

M Microcontroller profile:

• Implements a programmers' model designed for low-latency interrupt processing, with hardware stacking of registers and support for writing interrupt handlers in high-level languages.
• Implements a variant of the R-profile PMSA.
• Supports a variant of the T32 instruction set.

so there are multiple flavors of "architecture". There's the top-level architectures, which just have a number, preceded by "ARMv"; there's the profiles of those architectures, which add "-P" for the profile; and there are instruction sets, which they don't refer to as "instruction set architectures".

The "ARM® Architecture Reference Manual ARMv7-A and ARMv7-R edition" says similar things in section A1.3 "Architecture versions, profiles, and variants", with the A and R profiles supporting "the ARM and Thumb instruction sets" and the M profile supporting "variant of the Thumb instruction set", and section A1.2 "The instruction sets" says

The ARM instruction set is a set of 32-bit instructions providing comprehensive data-processing and control functions.

The Thumb instruction set was developed as a 16-bit instruction set with a subset of the functionality of the ARM instruction set. It provides significantly improved code density, at a cost of some reduction in performance. A processor executing Thumb instructions can change to executing ARM instructions for performance critical segments, in particular for handling interrupts.

ARMv6T2 introduced Thumb-2 technology. This technology extends the original Thumb instruction set with many 32-bit instructions. The range of 32-bit Thumb instructions included in ARMv6T2 permits Thumb code to achieve performance similar to ARM code, with code density better than that of earlier Thumb code.

From ARMv6T2, the ARM and Thumb instruction sets provide almost identical functionality. For more information, see Chapter A4 The Instruction Sets.

It also mentions ThumbEE and Jazelle.

Section F6.1 "The A32 and T32 instruction sets" of the ARMv8-A manual says

This chapter describes the changes that ARMv8-A makes to the T32 and A32 instruction sets, compared to an ARMv7-A implementation that includes all of the following extensions:

• Multiprocessing Extensions.
• Large Physical Address Extension.
• Virtualization Extensions.
• Security Extensions.
• VFPv4.
• Advanced SIMDv2.

So it sounds as if ARM have three instruction sets:

• "ARM"/"A32", the classic 32-bit ARM instruction set;
• "Thumb+Thumb-2"/"T32", the Thumb instruction set in both its original 16-bit flavor and its extended flavor;

"A64", the 64-bit ARM instruction set.

This is a bit complicated, but I guess it's what happens when you design a 32-bit instruction set and processor cores for a line of personal computers, find that the line of personal computers couldn't fight very well against the IBM PC and MS-DOS but also find that the processor cores are really popular in other markets, and end up trying to cover all of "the digital world" from microcontrollers in your washing machine to Big 64-Bit Blade Servers.

The table in this article, however, speaks of "ARM" and "ARMv8-A", in a fashion that mixes the variants of the ARM architecture and the various instruction sets a bit. Perhaps it should, instead, have entries for "ARM/A32", various flavors of Thumb, and A64, i.e. for the three current instruction sets, with the "Version" column indicating which versions and profiles of the ARM architecture have those flavors. "Extensions" could indicate that some versions and profiles of the ARM architecture might make a formerly-optional extension mandatory. Guy Harris (talk) 00:31, 30 May 2015 (UTC)

Wrong information on the architecture of x86!

x86 is publicly recognised the IA-32 architecture, so the description of it on that table is wrong! — Preceding unsigned comment added by 119.53.117.67 (talk) 09:29, 27 May 2017 (UTC)

Yes, we know that that's your opinion (no matter how vehemently you state it on no matter how many talk pages).

But as many of us have tried to tell you many times before, there are many references that say otherwise.

• From The X86 Microprocessors: Architecture And Programming (8086 To Pentium) [4]: page 51 - "We will start our learning of the x86 family of microprocessors, by understanding the architecture of the 8086, on which is based the architecture of the whole family." page 73 - "We should concern ourselves with assemblers for the x86 family of processors, which includes the whole set from 8086 to Pentium." (emph. added)
• From PCworld [5]: "Intel's 8086 microprocessor spawned the x86 standard for personal computers."
• From CPU-World [6]: "The third generation of x86 microprocessors, Intel 80386 (i386) was a 32-bit microprocessor backwards compatible with previous generations of 80x86 CPUs." (So quite obviously they consider the 8086 through the 80286 as being x86 first and second gen - if not them, then what?)
• From Computer Organization and Design: The Hardware/Software Interface [7], page 168: "Rather than show the entire 16-bit and 32-bit instruction set ((of x86 - the entire paragraph is clearly about x86 - jeh), in this section we concentrate on the 32-bit subset that originated with the 80386..." (emph. added)

Incidentally, the term "x86" likely derived from "iAPX 86", another name for the series from the 8086 onward. [8]

Also just btw, in that last book, the preceding page clearly describes x86-64 as "a set of architectural extensions" to the "x86 architecture". Not an architecture in and of itself.

Jeh (talk) 09:56, 27 May 2017 (UTC)

No, you misunderstand them! I've read those things you provided, just like the enhanced version of PAE, you fail to comprehend what those writers talk about actually. I wish you stop, if you could not make any improvement actually on those wiki articles. Through all your words since 2009, you confuse the processors with processor architectures, you confuse the x86 with x86-64. You confuse too many and many things, you did not even improve any related article at all. If you do not really understand something, I wish you stop confusing others, especially those poor and innocent readers from all over the world. And for the last words, please stop forcing your confused imaginations on others, who you could never understand! Just stop! 119.53.117.67 (talk) 10:57, 27 May 2017 (UTC)

Yeah yeah. Of course you would say that, wouldn't you?

Please then tell us, precisely and thoroughly, how you can interpret each of those references in a way that supports your opinion.

Just claiming "you misunderstand them!" says nothing; after all, we already know you disagree. But if you expect any changes to the article based on your opinion, you must now justify your disagreement with those reliable sources that state that your opinion is wrong. You need to provide an explanation for how each of these statements can be considered consistent with your claim of "x86 is publicly recognised the IA-32 architecture" [sic], when all four of them clearly and unambiguously equate the beginning of x86 with the 8086.

Yes, many recent writers do seem to think "x86" is only 80386 and later. It is perhaps a fact to be noted that people sometimes use "x86" only in the 32-bit sense. But we would regard that usage as wrong, as ignoring history... for the simple reason that the 8086 through 80286 were called "x86" before the 80386 ever existed. So obviously "x86" could not mean only the 32-bit x86!

You can't just ignore those uses and you can't just say "they don't really say that". They do. Jeh (talk) 11:09, 27 May 2017 (UTC)

For all the time, you deny two things,

I. x86 is an architecture rather than architectures.

II. x86-64 is an architecture rather than 64-bit version of x86 ISA.

What is the view of Intel 80386 processor on your mind? Only a processor with 32-bit ISA within protected mode? No! Nobody says something like that, and you won't say something like that too. Intel 80386 is a 32-bit processor, it provides three different operating modes on the same architecture, x86 or IA-32 architecture, and that is the first and final version of x86 or IA-32 architecture. The architecture of 8086, the architecture of 80186 and the architecture of 80286 eventually evolve into the architecture of x86 (IA-32). They are the one, but only at different phases of evolution. Books written by Darwin might help you understand such thing. The relationship between x86-64 and x86 might be compared with not a good example. The people mostly from Great Britain created a strongest country all over the world, and that is U.S.A. They use the similar language as the people in England, then can you call them English? Yeah, they might be English, if their ancestors came from England. But they are American!

• "From The X86 Microprocessors: Architecture And Programming (8086 To Pentium) [1]: page 51 - "We will start our learning of the x86 family of microprocessors, by understanding the architecture of the 8086, on which is based the architecture of the whole family." page 73 - "We should concern ourselves with assemblers for the x86 family of processors, which includes the whole set from 8086 to Pentium." (emph. added)"

• "From PCworld [2]: "Intel's 8086 microprocessor spawned the x86 standard for personal computers."

• "From CPU-World [3]: "The third generation of x86 microprocessors, Intel 80386 (i386) was a 32-bit microprocessor backwards compatible with previous generations of 80x86 CPUs."

• "From Computer Organization and Design: The Hardware/Software Interface [4], page 168: "Rather than show the entire 16-bit and 32-bit instruction set, in this section we concentrate on the 32-bit subset that originated with the 80386..."

Oh, my gosh! They just support my viewpoint! 119.53.117.67 (talk) 11:41, 27 May 2017 (UTC)

LOL. No. Jeh (talk) 11:46, 27 May 2017 (UTC)

Nobody would simply buy a word, "No", so do I! But I just respect your reply! 119.53.117.67 (talk) 11:52, 27 May 2017 (UTC)

My examples support my point, not yours. It is obvious with even the most basic understanding of English that , for example, "the x86 family of processors, which includes the whole set from 8086 to Pentium" says that x86 is not just the 32-bit CPUs.

Or, from the CPU-world quote, that if the 80386 was the "third generation of x86" then there had to be two generations before it. And we all know those were the 16-bit x86. etc.

If you expect anyone to read those quotes and conclude that any of them are saying anything but that x86 began with the 8086, then your grasp of English must be even worse than I've always thought it to be. And that's saying something.

"For all the time, you deny two things" - again, those "two things" are your opinions. And it's not me who denies them. I follow what I find in reliable sources. Like the ones quoted above, and the AMD64 architecture manual. You are of course free to follow whatever you dream up in your own head (or pull out of... wherever) but Wikipedia will not be edited to match your opinions unless you can find far better sources and arguments than you have so far. Jeh (talk) 11:46, 27 May 2017 (UTC)

Why the large part of this reply does really support my viewpoint? You might confuse instruction set architecture with instruction set, so you failed to comprehend the actual meaning in your own examples. Through your words, I could also see a picture of you, you prefer to guessing or imagining others, criticising the ones you look down upon, maybe only for the region. That might be also the reason that you emphasise China all the time. But it does not matter, I just wish you clean up your mind, and accept the right from confused. Good luck! 119.53.117.67 (talk) 12:14, 27 May 2017 (UTC)

Let's try it the other way around. How do you claim that "the whole set from 8086 to Pentium" excludes 8086 through 80286? How do you claim that "80386 was the third generation of x86", given that 80386 was the first 32-bit x86, does not include 8086 through 80286 as the first two generations of x86?

And if 8086, 80186, and 80286 are not x86, then why were they called x86 then? And what do you call them now, since you claim they're not x86?

Reality (regardless of your opinion) is that "x86" is a generic term that covers everything from 8086 through x86-64. If you want to refer to just the 64 bit-capable CPUs you can say x86-64 or x64 (and yes, those are the same - if you disagree, do not simply say I'm wrong, find references that explicitly say they're different!). If you want just the 32-bit machines you can say x86-32, or "32-bit x86". etc. The usage in the table is correct.

And btw, not that I see any relevance to the discussion here... but "instruction set" and "instruction set architecture" are used interchangeably, whether you believe it or not.

The term used to just be "instruction set". "Instruction set architecture" is a fairly recent shift in usage. It gained favor not because it means something different from "instruction set", but to distinguish that type of "computer architecture" from other aspects, such as the microarchitecture or the bus/interconnect architecture.

I conclude that you have read these two terms in different places and assumed that they just must mean something different, and so you have invented the differences in your mind, not realizing that this is just an example of evolving terminology.

Since you disagree, I must ask you to describe exactly and precisely what you think the difference is between "instruction set" and "instruction set architecture". For example, if I describe only a CPU's "instruction set", what part of the "instruction set architecture" have I not described? Or vice versa?

Or, just cite a reliable source - preferably two or three - that says that they're different and says how they're different. Jeh

Just to get you started, here are notes from a university course on the subject. The author freely switches back and forth between "instruction set" and "instruction set architecture" (or "ISA"), uses both terms to refer to the same things (instructions, registers, addressing modes, etc.) and never says that they're different... let alone how they're different. So, how do YOU think they're different, and what RSs do you have for that opinion? (Darwin doesn't count.) Jeh (talk) 12:51, 27 May 2017 (UTC)

I have a question, do you have problems when you chat with British people? OK, just treat it a joke, or forget it. I never said that 8086/8088, 80186/80188 and 80286 are not x86 processors. I just said they shared the one architecture, but only at different phases of evolution. Yes, I go agree with you that some people use the term, x86-32. People use this term for the following purposes:

• 1. They believe that the x86-64 is the 64-bit version of x86, in other words, x86 architecture evolved into its 64-bit version. So the legacy instruction set is referred as x86-32.
• 2. They understand that the x86-64 is a 64-bit architecture, extended from legacy x86 (IA-32) architecture. But they just keep the balance with x86-64, and refer that legacy architecture as x86-32.

Neither Intel nor AMD would make any judgement about that, because they want more and more people purchase their processors. But both of them deny the first presumption above inexplicitly, especially for the value, family number, in CPU ID. Without talking about extended processor id, Intel set that value as 0x6 for all their current processors, since Core 2 (successors of Pentium 4); AMD, on the other hand, set that value as 0xf since Opteron released. This implies two things,

• 1. Intel denies that the Intel 64 architecture is designed for the 7th generation of x86 processors. They treat x86-64 just as a 64-bit extended ISA on their enhanced 6th generation of x86 processors;
• 2. AMD denies that their AMD64 processors are merely the x86 processors. They treat them as the real 64-bit AMD64 (x86-64) processors, backward-compatible with programmes written for x86, platform based on x86, rather than 64-bit version of x86 processors.

And the fact that almost every software vendor differentiate them both, including FreeBSD, Linux, Microsoft and so forth. As to the instruction set and instruction set architecture, you know the MMX(+) and 3DNow!(+) are the instruction set extensions to 80x87, they three share the one architecture. That is the difference between them both. I've never thought I were different, that might only happens in your own view. 119.53.117.67 (talk) 13:39, 27 May 2017 (UTC)

So you're right, because you're now denying that you said what you said before, and now you're saying something else. Got it.

I knew you wouldn't come up with actual references - just more armwaving. Your conclusions from your faulty logic based on history that didn't happen and your interpretation of words that you have made up on the spot to justify your opinion - which you won't even stick to.

You have cited no RSs that prove, or even imply, that the table is wrong. I have cited RSs that show that it is correct. Until you can do better - and that does not mean your ludicrous claims that my sources support your opinion - I really don't see why you continue here. Jeh (talk) 13:59, 27 May 2017 (UTC)

"So you're right, because you're now denying that you said what you said before, and now you're saying something else. Got it.", I've never denied what I said before, maybe your confusions assist you denying everything you are unable to understand, such as 46-bit virtual address problem in second half of 2014. 119.53.117.67 (talk) 14:21, 27 May 2017 (UTC)

I notice you still haven't cited any RSs that support your claims. (Any version of your claims.) Jeh (talk) 14:34, 27 May 2017 (UTC)

See the table in x86, why there is something like "14 / 16", just because in second half of 2014, you were unable to understand the 46-bit virtual address, so you forced others to believe what you denied. If you want RSs, you can seek it in the history of that talk page. You have already cited the things supporting my viewpoints. Thank you. 119.53.117.67 (talk) 14:45, 27 May 2017 (UTC)

"There is something like "14 / 16"" because, in the 80286, a segmented address has 14 bits of segment number and 16 bits of segment offset. That has, as anybody who actually understands that column would know, nothing to do with 64-bit x86. So your claim that the values in the "Segment / offset size (bits)" column are there "just because in [the] second half of 2014, [Jeh was] unable to understand the 46-bit virtual address" is completely untrue. In mid-2014, there was no "Segment / offset size" column; there was a "Linear/physical address space" column, but there was no "14 / 16" there because no x86 processor had 14-bit linear addresses and 16-bit physical addresses. Guy Harris (talk) 19:34, 27 May 2017 (UTC)

Listing different bit-widths for an ISA separately?

With the exception of ARM, which is somewhat of a special case (as it has multiple instruction sets - ARM speaks of A32, T32, and A64 as separate instruction sets), we combine multiple bit widths for a given ISA into a single row.

One editor has been splitting x86 into multiple rows; is there any fact-based reason to do this, for x86 or any other ISA? Guy Harris (talk) 00:18, 28 May 2017 (UTC)

In general I would say no. Not when we have multiple reliable sources that say they're all variants, versions, extensions, whatever word you like there, of x86. In particular x86-64 is not a separate architecture from x86, and x86 is not separate from 8086 through 80286. Jeh (talk) 01:19, 28 May 2017 (UTC)

We need more and more real IT experts get involved into this discussion rather than only minors! But your reply is appreciated at some extents. 221.9.12.41 (talk) 01:21, 28 May 2017 (UTC)