Talk:Comparison of instruction set architectures

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Hardware (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by Computer hardware task force.


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. (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"[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. (talk) 05:34, 27 November 2010 (UTC)

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)

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

Comparison of CPU architecturesComparison 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)


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)


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)

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

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.


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.


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).
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)