Talk:Comparison of instruction set architectures

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

Scope[edit]

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)[reply]

I agree. 208.118.18.233 (talk) 05:34, 27 November 2010 (UTC)[reply]
So do I. I added a section to suggest the rename. Guy Harris (talk) 08:36, 3 December 2013 (UTC)[reply]
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)[reply]
Do we need an RFC on the scope of the article? Should the lead describe the scope?
Off the top of my head, I'd suggest adding to the table, e.g.,
  1. 12-bit computing
  2. 16-bit computing
  3. 18-bit computing
  4. 30-bit computing
  5. 32-bit computing
  6. 36-bit computers
  7. Atlas
  8. Burroughs large systems
  9. Decimal computers
  10. English Electric KDF9[d]
  11. IBM 7030 Stretch[e]
  12. Intel
  13. Motorola
  14. SDS Sigma series
  15. UNIVAC LARC[f]
I've added some notes. --Revised 18:59, 21 November 2022 (UTC)
The 680x0 series is already there - it's the third row of the table. Guy Harris (talk) 03:07, 21 November 2022 (UTC)[reply]
Shouldn't the table include vendor as well as number, e.g., MC 680x0 instead of 680x0? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:51, 21 November 2022 (UTC)[reply]


  1. ^ Original processor for UNIX.
  2. ^ Original processor for Multics
  3. ^ Early Stack machine with segmented virtual memory
  4. ^ Early stack machine.
  5. ^ Early supercomputer.
  6. ^ Early supercomputer.

"Open" and "Royalty-free"[edit]

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)[reply]

Further, most of the entries in the table are unsourced. I don't want to put a {{dubious}} on every questionable entry, but putting {{dubious}} on the entire table is probably not legitimate. I've worked on multiple instruction sets from multiple vendors, and for none of them has the vendor made an intellectual property claim on the instruction set. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:46, 17 October 2021 (UTC)[reply]
In that case then any company would be able to make an x86 processor, which I believe is not the case. I think a x86 license is needed from Intel. As for ARM I think they have different license too depending if you want a license for the ISA or for the microarchitecture. Sounds like you have some experience with ISA so please contribute to the article. -- Frap (talk) 08:23, 18 October 2021 (UTC)[reply]

Number of registers in "Instruction sets" table[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

The Z80 is listed with 17 registers, a rather puzzling number. Specifically, it has six 16-bit registers AF/BC/DE/HL/IX/IY which are addressable also as 8-bit pieces (though some of the opcodes were undocumented) and an entire duplicate set of all of the above. 108.183.39.162 (talk) 17:09, 19 February 2019 (UTC)[reply]

It's a bit weird, but not that puzzling. You have 7 byte addressable registers and a second set to go with it and then you have the three pointers. Together that adds up to 17. The person who wrote it decided to count based on all the saperately addressable registers. — Preceding unsigned comment added by Darth milium (talk • contribs) 05:48, 20 February 2019 (UTC)[reply]
I also am puzzled by the Z80 count. I count A, B, C, D, E, H, L, the seven primes, IX an IY. That is 16. (F is never byte addressable.) Should SP be counted as it can be the source of an ADD? If so, should the 8080 registers be counted that way too?~~ RastaKins (talk) 15:44, 24 October 2022 (UTC)[reply]

Requested move 03 December 2013[edit]

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)[reply]


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)[reply]

Survey[edit]

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.

Discussion[edit]

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?[edit]

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)[reply]

Or, as per the "Scope" section above, just remove the table. Guy Harris (talk) 21:29, 11 December 2013 (UTC)[reply]
Move it to a new article. -- Frap (talk) 13:14, 23 December 2013 (UTC)[reply]
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)[reply]

Vector/accumulator register included (for some)[edit]

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)[reply]

ARM architectures vs. ARM instruction set architectures[edit]

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)[reply]

Wrong information on the architecture of x86![edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
LOL. No. Jeh (talk) 11:46, 27 May 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]

"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)[reply]

Also, Intel says that "Intel introduced the x86 architecture on 1978 with the 8086 cpu (it was a 16-bit cpu).", "In 1985, enhanced the x86 architecture with the 80386 cpu, and since this one was 32-bit, the term IA-32 was implemented. ", and "AMD introduced x86-64 in the year 2000. x86-64 is defined as the 64-bit version of the x86 instruction set." - as well as "The answer was provided by one of our processors engineer." in response to a question by some user named "Janagewen" who asked "is this answer on the behalf of Intel. or just you?" Guy Harris (talk) 03:27, 28 May 2017 (UTC)[reply]
"The answer was provided by one of our processors engineer.", wow, wow, wow, people working for Intel are quite smart (even though with grammar errors)! On behalf of "one of our processors engineer", could it stat that that is the statement from the Intel towards the world around? No, just towards me, and whoever pays visit there! And Guy Harris once said things from communities could not be treated as sources. Please do not eat your words! Wikipedia.org should stand on the neutral position, I wish that is not the evidence that you earn money from Intel. 221.9.12.41 (talk) 03:38, 28 May 2017 (UTC)[reply]
Community-provided content can't be used as references for articles, but they certainly can be mentioned in talk page discussions. So your defense, though the answer exactly contradicts you, is that that answer would be somehow different if it was presented to "the world around"? Hilarious! If that were a reasonable position then we could never use any reference ever for anything. Jeh (talk) 04:22, 28 May 2017 (UTC)[reply]

Listing different bit-widths for an ISA separately?[edit]

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)[reply]

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)[reply]
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)[reply]
If you knew anything about the industry and the business you would know that "IT", except in the absolute broadest sense of the term, has very little concern for the details of instruction set architectures. Most "IT" people couldn't tell you the difference between a register and an opcode. (Nor do they need to!) Jeh (talk) 01:31, 28 May 2017 (UTC)[reply]
I presume by "minor" you don't mean a person under the age of majority, as at least two of the people in this discussion are decades over 18 (the age of majority in the US) - presumably you are over the age of majority in your country as well. Guy Harris (talk) 03:34, 28 May 2017 (UTC)[reply]
It seems that your style is misleading, just like you did on wiki article, Solaris, please take a look at the talk page of that. I mean minor as "not very large, important or serious". Please do not judge whether it is right or wrong what OALD says. If you want to mis-understand or mis-comprehend my words intentionally, that is only to tell the world that all your words around related discussions are only provided to confuse readers from all over the world...221.9.12.41 (talk) 03:48, 28 May 2017 (UTC)[reply]
Ah, there it is. The good old "misleading" accusation. Janagewen's favorite retort. Nobody who disagrees with Janagewen can ever possibly be right. Even when Janagewen is refuted with solid references and iron-clad references, he waves it all away (or so he thinks) by calling it "misleading," accusing of being intentionally confusing, or by accusing of paid editing. Jeh (talk) 04:19, 28 May 2017 (UTC)[reply]
Just in case you weren't aware of it, pointing people to the nonsense you posted here is not a good way to convince sane people that you know what you're talking about.
And you haven't presented anything to indicate that you're even remotely close to being "large, important, or serious" here? What are your credentials? What do you mean when you say you "studied computer architecture since 2004"? In what depth have you studied them? Guy Harris (talk) 04:51, 28 May 2017 (UTC)[reply]
Well, thank you for reading my words. I have never said that I am important, but all the time you both consider I were. So this discussion needs the real IT experts get involved! Please do not confuse yourself, and confuse others. 221.9.12.41 (talk) 04:56, 28 May 2017 (UTC)[reply]
So what is a "real IT expert"? I guess people who have worked for many years writing code, including kernel-mode code, for multiple instruction set architectures aren't "real IT experts", otherwise, two out of the three people who have contributed to this talk section are, in fact, people who have worked for many years writing code, including kernel-mode code, for multiple instruction set architectures. What have you done that anybody should take any of what you say here seriously? Guy Harris (talk) 05:01, 28 May 2017 (UTC)[reply]
If I remember right, he's read some magazine articles. Jeh (talk) 05:20, 28 May 2017 (UTC)[reply]
That's pretty much what I figured. Fanboy city.... Guy Harris (talk) 05:32, 28 May 2017 (UTC)[reply]

What else?[edit]

We don't need to list every architecture that ever was here, but what historically significant ones are we missing?

I suggest that the PDP-8 and HP 2100 (in many ways, a PDP-8 extended from 12 to 16 bits) are worth the pixels.

I also have a strange fondness for the IBM 1401, but a simple line in a table like this cannot begin to describe the quirkiness of that machine. :) Jeh (talk) 07:14, 28 May 2017 (UTC)[reply]

Historically significant? PDP-6/PDP-10 and Data General Nova/Eclipse/MV (and the rather Nova-influenced Xerox Alto?) might be worthy as well. Guy Harris (talk) 07:35, 28 May 2017 (UTC)[reply]
As I understand it the DG Nova had a lot in common with the HP 2100, both borrowing a lot from the PDP-8. I can do the HP 2100 and PDP-8 entries. The Nova, and Eclipses, no. And honestly its article could stand having a lot of detail added.
Should we add a column for "stack", meaning a dedicated stack register, push/pop instructions, stack automatically used by CALL, etc.? One of the most remarkable things to me about this is how many architectures didn't have a stack - notably IBM S/360 through Z-architecture! Jeh (talk) 09:17, 28 May 2017 (UTC)[reply]
Perhaps, although neither a dedicated stack pointer nor a "push the PC onto a stack and branch" instruction are requirements for recursion - I wonder whether S/3x0's relatively simple procedure call instruction was an inspiration for any of the RISC ISAs (especially POWER/PowerPC/Power ISA).
The PDP-6/PDP-10 didn't have a dedicated stack pointer register, but they did have push/pop instructions and a procedure call instruction that automatically pushed the PC onto the stack; any GPR ("accumulator") could be used as the stack pointer register. And, of course, the PDP-11, VAX, and m68k had a register that was a dedicated stack pointer, but didn't have push/pop instructions - they just used auto-increment/auto-decrement addressing modes with SP. So I guess we'd have to decide what does, or doesn't, indicate that the ISA supports a stack, or give separate answers for "ISA explicitly designates a register as the stack pointer", "ISA has push/pop instructions for data", and "ISA has push-and-jump/pop-and-jump instructions". Guy Harris (talk) 17:44, 28 May 2017 (UTC)[reply]
The VAX does have dedicated PUSH/POP instructions. MOVL is opcode D0 while PUSHL is DD. The latter takes no operand specifier byte for the destination, it assumes -(SP), so is one byte shorter in the instruction coding. (And then there's PUSHR/POPR.)
But your point remains: There are a lot of variations around "does it have a stack?" I think "does it use stack-based procedure call/return?" is the salient question. I'd say this would be "yes" for the all of the machines you mentioned except the m68k, which I don't know about. The "write the return address to the destination location" method used by the PDP-8, HP 2100, and many others of that era would be firmly on the "no" side. Jeh (talk) 23:55, 28 May 2017 (UTC)[reply]
Oops, forgot about the PUSH/POP instructions. My introduction to UN*X was on the PDP-11, and the -11 in question also ran RT-11, so I dealt more with PDP-11 than VAX assembler. I guess they added PUSH/POP to have a shorter opcode for common operations.
The 68k used address register 7 as a stack pointer and had jump/branch to subroutine ("jump" as in "arbitrary address mode for the destination address" and "branch" as in "offset from the current PC as the destination address") instructions, which pushed the PC on the stack, and return from subroutine, which popped the new PC value off the stack, so it's definitely in the "stack-based procedure call/return" category. It had no general push or pop instructions, using instead the move instruction with pre-decrement or post-increment of A7, PDP-11-style.
The PDP-6/PDP-10 supported "write the return address to the destination location" calls, with Jump to Subroutine, "write the return address to a register", with Jump and Save Program Counter, and "push the return address onto a stack" calls, with "push and jump" and "pop and jump" instructions; I guess they wanted to appeal to everybody, no matter what procedure-call style they were used to :-). They also had push and pop instructions. There was no stack pointer register - any "accumulator", i.e. GPR, could be used.
The various RISC architectures, and System/3x0+z/Architecture, don't enforce stack-based procedure calls, but they make it possible and, in practice, that's probably what's used in practice these days, except perhaps for programming languages that don't require recursion (if there are any these days, and if anybody actually bothers to implement them without recursion) and leaf routines if you don't need to store the register holding the PC on the stack. The calling convention in OS/360 and successors is callee-save - in a location provided by the caller. (The standard OS/360-and-successors procedure call puts the return PC into R14, with the save location pointed to by R13.) The save area could be on a stack, or dynamically allocated (I seem to remember some IBM documentation using GETMAIN to allocate save areas dynamically), so it could support recursive calls, but it could also not support recursion. UN*Xes for S/3x0 and z/Architecture use C-style calling sequences, with a stack. The RISC processors probably use C-style calling sequences everywhere.
The IBM 1130 is another "write the return address to the destination location" ISA.
The Nova's Jump to Subroutine saved the PC in AC3, which was also usable as an index register, so it could implement stack-based calling but didn't enforce it. (The Nova had four "accumulators", all of which were usable as GPR operands; AC2 and AC3 were also usable as index registers.) Guy Harris (talk) 01:40, 29 May 2017 (UTC)[reply]
Personally I think this page is a bit of a mess. It misses some highly influential architectures like nova data general and a lot of earlier mainframe designs, but has weird instruction sets included like the Elbrus, which were really niche. Until yesterday it even included the 65k, which is just some random persons personal extension to 6502. I would personally like to see some more designs added in general. Also why is there a distinction between arm 7 and arm 8, but no distinction between x86 and x64 Darth milium (talk) 09:45, 17 February 2019 (UTC)[reply]
Arm A32 and A64 are significantly different, with the latter not only having twice as many GPRs but also lacking instruction predication. 32-bit and 64-bit x86 are more different from each other than are most 32-bit and 64-bit ISA versions, but less so than A32 and A64 - most of the work of making them different is done by the REX prefix. So the case for separating 32-bit x86 and 64-bit x86 is weaker than the case for separating A32 and A64. (A case could perhaps also be made for separating A32 and T32 - Arm refer to all three of them as instruction sets.) Guy Harris (talk) 12:25, 17 February 2019 (UTC)[reply]

I could suggest a few that are missing: CDP1802, 6809, NEC V60 and V810 108.183.39.162 (talk) 17:03, 19 February 2019 (UTC)[reply]

Please involve into it, if you think there are someting worthy reading...[edit]

https://en.wikipedia.org/w/index.php?title=Comparison_of_instruction_set_architectures&oldid=782604046

This is a new starting like all my other efforts on Wikipedia.org have been kicked out by only very few persons, that takes non-sense. If you find it a little bit worthy, you are welcome to involve in it to improve the main article, such as correct wrong information to it. — Preceding unsigned comment added by 221.9.14.172 (talk) 07:16, 28 May 2017 (UTC)[reply]

I am not strongly in favor or opposed. I think it was a good initiative to be bold, but once reverted it should have been left in the reverted state for a discussion in this talk page. Forcing your edits when its been reverted and getting into a edit war is childish, unprofessional and against the conduct of Wikipedia. Using sockpuppets is unacceptable, Wikipedia works by adhering to the community guide lines and consensus, trying to bypass that using socketpuppet is egoistic, selfish and against the conduct of Wikipedia. We need to put our egos aside and collaborate together to make Wikipedia great. We also need to remember what Wikipedia is and Wikipedia:What Wikipedia is not. Articles should be comprehensive and get a provide a overview of a subject, it need not delve into every little detail in every iteration of an architecture. The article is much more useful if it provides a easy-to-grasp, conceptual overview so you can compare example ARM to x86. Maybe there should be another article example "Evolution of the x86 architecture" that goes in more detail on the changes between the iterations which takes up all the changes between like early phase of x86 and later versions. -- Frap (talk) 16:59, 28 May 2017 (UTC)[reply]

PIC microcontrollers instruction set[edit]

Should not https://en.wikipedia.org/wiki/PIC_instruction_listings be in the list? — Preceding unsigned comment added by Urquan8 (talk • contribs) 09:12, 23 May 2018 (UTC)[reply]

Performance Comparisons[edit]

I think it's worth having a section that details how using newer instruction sets affects clock cycles and under what circumstances. This information would be incredibly useful when trying to code for compatibility with older processors.

With Intel developing new instruction sets, AMD is one step behind with their instruction sets, meaning a processor can still have more than enough processing power, but be unable to run a program due to lack of support for processors without the new instruction sets. A developer could use performance info related to certain tasks to decide what sections of code to compile without SSSE3 and newer instruction sets, and what sections of code would benefit from being compiled with a newer set, if the user's machine supports it. I was looking for the info about that, but afaik it's not well documented in one location like could be done on wiki. — Preceding unsigned comment added by 107.179.238.99 (talk) 22:22, 27 February 2019 (UTC)[reply]

Neither Intal nor AMD appear to be developing new instruction set architectures - they're making x86 processors, mostly 64-bit.
What they are doing is extending the existing x86 instruction set architecture, adding new instructions to them. That's what all the links in the "Extensions" column of the "8086/x86" row are - links to various extensions to x86.
So anything discussing particular extensions to particular instruction set architectures doesn't belong here; this page doesn't compare various extensions to the instruction set architectures it lists, it compares the instruction set architectures as a whole. The same applies to extensions to other instruction set architectures, such as ARM, z/Architecture, SPARC, etc., etc., etc..
Furthermore, Wikipedia is not a manual, so it's probably not the best place to read for that level of detail.
You might get some information about particular extensions by clicking on the appropriate link, e.g. SSSE3 if you're curious about SSSE3. You should also check the "External links" section for the pages in question for links to other pages that might have helpful information.
(And, yes, SSSE3 should be in the "extensions" table cell.) Guy Harris (talk) 23:15, 27 February 2019 (UTC)[reply]

Organization of page[edit]

Currently, #Bits, #Operands and #Endianness are subsections of #Base. The first and third are only relevant for binary computers, and the second belongs in a separate section. I propose the structure

  • Integer formats[a]
    • Bases
      • Binary
        • Endianess
        • Sign[b]
      • Decimal
  • Floating point formats[a][e]
    • Binary
    • Decimal
    • Octal
    • Hexadecimal
    • Assumed radix point
    • Normalization
    • Sign[b] of exponent and mantissa
  • Instruction formats[a]
    • Opcodes
    • Operands
      • Explicit
      • Implicit

I don't know enough about ternary computers to suggest how they should fit in. Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:08, 9 August 2020 (UTC)[reply]

Notes

  1. ^ a b c An architecture may support more than one.
  2. ^ a b E.g., ones' complement, two's complement, sign-magnitude.
  3. ^ E,g., the IBM 1401 had six bit characters with two zone bits used for the sign.
  4. ^ the IBM 7070, 7072 and 7074 had a three-state sign, +, - and alpha.
  5. ^ Categorized by what the exponent represents.

CDC 6600 a RISC[edit]

The CDC 6600 is missing two features from the classical definition of a RISC:

  • That all instructions have the same size
  • That all instructions take the same amount of time

On a peripheral processor (PP) an instruction may be either 12 bits or 24 bits; on a central processor an instruction may be either 15 bits or 30 bits; neither the CPs nor the PPs seem to fit the definition of RISC. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:18, 9 November 2020 (UTC)[reply]

As a counter-example, the ARM processor is generally described as 'RISC' but has both a 32-bit instruction set and a 16-bit instruction set (Thumb), so there is at least one RISC processor which does not have instructions all the same size.
The CDC 6600 was never at the time described as RISC, since that term had not yet been invented. It definitely has a load-store architecture and only a few simple addressing modes. Do existing RISC processors really perform all instructions in the same amount of time (consider floating-point, multiply/divide and similar)? In fact the 6600 could issue instructions on every clock cycle, provided they were for different functional units. Murray Langton (talk) 21:40, 9 November 2020 (UTC)[reply]
Does ARM have a single mode with variable length instructions, or merely several different modes? The CDC 6000 series CP has a single mode with variables instruction lengths, as does the PP.
Reduced instruction set computer says The main distinguishing feature of RISC architecture is that the instruction set is optimized with a large number of registers and a highly regular instruction pipeline, allowing a low number of clock cycles per instruction (CPI)., but on the 6600 execution times for arithmetic instructions range from 3 to 29 minor cycles. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:14, 10 November 2020 (UTC)[reply]
There's cycles spent in decoding, fetching operands, etc., and there's cycles spent performing the underlying operation.
RISC can minimize the former with "a large number of registers and a highly regular instruction pipeline", but if the implementation doesn't have a shifter, such as a barrel shifter, that can shift an arbitrary number of bits in one clock cycle, a shift instruction may take O(shift count) cycles, so the only way to make that take "a low number of clock cycles" is to either 1) make the maximum value of "a low number of clock cycles" be a number slightly larger than the number of bits in a register or 2) don't have multi-bit shift instructions (the latter, unfortunately, means providing an instruction set that has to be extended to make use of a barrel shifter).
Multiply and divide instructions might also take more cycles than you'd like. SPARC v7 solved that problem by not having them - it just had a "multiply step" instruction, with the compiler encouraged to special-case operations with a constant operand. (SPARC v8 added multiply and divide instructions.) MIPS had them; according to this USENET post by Charlie Price at MIPS, integer multiply takes 12 cycles and integer divide took 35 cycles on the R2000 and R3000. I don't know whether those count as "a low number of clock cycles"; I guess if they don't, the R2000 and R3000 weren't, according to somebody's criteria, RISC processors. :-)
I don't have instruction timings handy for floating-point operations on the R2000, but I suspect a floating divide isn't going to happen in a single-digit number of cycles. Guy Harris (talk) 05:37, 10 November 2020 (UTC)[reply]

Coverage?[edit]

What are the criteria for including an ISA from the table? Obvious candidates from, e.g., Burroughs, CDC, Cray, DEC, ETA, GE, Honeywell, IBM, RCA, SDS, UNIVAC, are missing. Which of these belong?

--Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:51, 8 December 2021 (UTC)[reply]

Already there:
It has the PDP-8 and the PDP-11, so it should probably have the PDP-6/PDP-10.
Given that it has the upper CDC 3000 series, it should presumably have the lower series.
The list is, in general, biased towards ISAs with microprocessor implementations; the ones that didn't start out as microprocessors are S/3x0 (presumably due to its dominance of the mainframe market, its survival to the present, and that survival including now being a popular host for a hip and trendy OS popular amongst the kids :-)), the most notable DEC machines (with the notable exception of the -6/-10 - the -8 and -11 presumably being there due to minicomputer dominance, and the VAX being there due to supermini dominance), the CDC 6000 (presumably because of its notability as a supercomputer), and the upper CDC 3000 (OK, what makes that one special?).
I'm not sure which of the ones in your list are worthy of inclusion, as I'm not sure what, other than "somebody wanted to put it there", were the criteria for including the existing ones. Guy Harris (talk) 22:19, 8 December 2021 (UTC)[reply]
IBM 709, IBM 7090 and IBM 7094 / IBM 7094 II instruction sets are available on IBM_System/360 and IBM_System/370 via special microcode and/or an emulation program. That would make their instruction set support lifetime from 1958 to 1977, about 19 years. (talk) 01:10, 19 November 2022 (UTC)[reply]
Expanding upon PDP-10 ISA with compatibles:
* DEC PDP-6/PDP-10/DECsystem-20, MAXC, Foonly, Systems Concepts SC-40, XKL TOAD-2, Tymshare System 26KL
I listed the largest models of any series of compatibles only. -- (talk) 15:53, 22 November 2022 (UTC)[reply]

Draft reorganization at User:Chatul/sandbox/ISA[edit]

I have written a suggested reorganization at User:Chatul/sandbox/ISA, replacing:

Please post any comments here, including a summary of any changes you make in the sandbox. If you're familiar with any ternary machines, please expand as appropriate. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:20, 25 April 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Comparison_of_instruction_set_architectures&oldid=1220744714"