Talk:Processor register

Attention flag

This article could probably use some attention from other folks familiar with the field. First of all, there's really no general explanation of what a register is, or how it's implemented in hardware. (Essentially a value associated with a particular address, stored in binary digits using electromagnetic storage.) This article focuses particularly on registers found in CPUs; I'm not sure if that should be included here, or if a general article should be created. The other, related problem is that there are lots of very short articles that describe CPU registers that are used for particular purposes. It's very hard to get an idea of how all these registers fit together by reading all these separate articles (unless you know how these things work already). I assume any given register (except for I/O, of course), will usually be assigned a certain function by convention, not because it's physically any different than any other register. (That issue is somewhat murky.) It may be that the best way to tie together all the various types of register would be to write a "how CPUs execute code" article, which doesn't seem to exist. This article is mostly just a parts list, which isn't all that illuminating. -- Beland 06:45, 11 July 2005 (UTC)

Having started assembly programming in the mid-70s it is my view that the article is a good start, could do with some expansion, some examples from well known processors (x86, 68K and ARM would seem appropriate) and a DSP (for instance DSP56300). I will address each of your questions in turn:

• there's really no general explanation of what a register is: In old style architecture it was quite simple: just a set of static RAM bits hardwired to specific CPU functions. In modern times we have register aliasing and other tricks to improve speed that complicates the issues. As an example: the instruction set architecture in Pentium is very similar as to, sat, the 386 processor, yet the internals is very, very different and horrifically complicated. So 20 years ago I could have given you a simple explanation that today would be misleading.
• or how it's implemented in hardware: Again, it used to be simple (latches and flipflops) but today we have register files (tables of registers implemented extremely fast RAM) that are dynamically mapped to specific functions.
• This article focuses particularly on registers found in CPUs: That simply is the title of this article. Mixing it with registers in SCSI, S-ATA, RAMBUS-memory or the like would seem irrelevant to me.
• It's very hard to get an idea of how all these registers fit together: Sometimes the registers are loosely connected, like floating point and integer registers on x86. You can convert but that is explicitly done.
• I assume any given register (except for I/O, of course), will usually be assigned a certain function by convention, not because it's physically any different than any other register. These used to be very, very different but with register aliasing, register files and more CPU-internal data busses things have become more flexible. The cost is design complexity, larger die sizes (to cater to all these busses) and speed (moving from hidden functional registers to programmer visible registers in the register file.
• his article is mostly just a parts list, which isn't all that illuminating. Assembly programming can be somewhat arcane but given a few days of hands on assembly programming you learn the logic of it all. The problem is that there is no standard, x86 and 68K are very different, in fact the ISA is what defines the differences and teh behaviour to the programmer. -- Deleteme42

CPU cache

This article is talking about the same thing as the CPU cache. The names are pretty much meaning the same thing, as register synonymous to cache, and CPU to processor. Perhaps we should merge these together. --Bookinvestor 10:40, 1 December 2007 (UTC)

No, registers are not the same as cache. Registers are either used to hold the values that are being used by the execution units or to configure the processor, while caches are used to hold instructions or data that are frequently used by the processor. They may be implemented with the same kind of memory (SRAM) but that is where the similarity ends. Rilak 06:05, 2 December 2007 (UTC)

Maybe I'm being picky but there's a problem with the first x86 example

Hi there I was just looking around Wikipedia for some information about the registers in the x86 architecture and the x86 article itself conflicts with the first example on this page about the x86 this article states that.

"For instance, the x86 instruction set defines a set of eight 32-bit registers"

however the x86 architecture began as a 16-bit architecture so 32-bit registers are not actually a requirement of the x86.

"With the advent of the 32-bit 80386 processor, the 16-bit general-purpose registers, base registers, index registers, instruction pointer, and FLAGS register, but not the segment registers, were expanded to 32 bits. " - from Wikipedia/x86 - 32-bit registers section

I'm going to go ahead and change "For instance, the x86 instruction set defines a set of eight 32-bit registers" to something like "For instance, the x86 instruction set defines a set of 16-bit registers however most modern x86 processors have extended these to a length of 32-bits" the number of registers also seems to be a bit off as the origional 16-bit x86 had 14 16-bit registers the 32-bit must have 10.

No I think I'll just substitute x86 for IA-32 and remove the number eight. I think that will do.

This is a talk page. Please respect the talk page guidelines, and remember to sign your posts by typing four tildes (~~~~).

thanks for the reminder

BobMan801 10:04, 6 July 2010 (UTC)

Stack pointer as integer register (in 6502)

You wouldn't usually think of the stack pointer as a general (purpose) integer register (in 6502). But couldn't you use it as one? Maybe include or add as a note. I'm asking since W65C816S (a variant it seems), seems to include SP in the count (and ARM, where it really is general). Is there a reson it should be counted there and not be consistent? comp.arch (talk) 15:02, 4 June 2013 (UTC)

The Dec PDP-11 nominally had 8 registers, but one was used as the stack pointer and one as the instruction counter. You could indeed do arithmetic on either of these registers e.g. for removing parameters from the stack you just adjusted the stack pointer using an ADD or SUB instruction. The DEC VAX was similar, but with 16 registers instead of 8. Murray Langton (talk) 16:15, 4 June 2013 (UTC)

IBM Cell

Can't figure out IBM Cell in the table. Maybe it should me listed as 'SPEs (in IBM's Cell)', because the Cell includes Power arch (PPE) that obviously has more registers. I'm not sure what the integer and FP cells mean. I think they should be unified to one cell, since the SPEs seem to be unified (are there more registers?) See: http://wiki.riteme.site/wiki/IBM_Cell#Synergistic_Processing_Elements_.28SPE.29

Another (cleaner) unified integer and floating point, non-vector, though multi-core, Epiphany, could be added as an unified example. That one has 32 32-bit unified registers (per core, that are 16 or 64 or up to 4096 in the future). comp.arch (talk) 15:46, 4 June 2013 (UTC)

Etymology

Does anyone have any information about how the word register came to be used for this part of a computer? Apart from pure speculation, that is. --User:Dolda2000 (talk) 05:23, 2 April 2014 (UTC)

General purpose register

Regarding GPR (in Template:Infobox CPU architecture) the general means "generally used in the same way" as opposed to the special purpose registers? I'm thinking of hardwired-to-zero "registers", they can be used as a source as any other. But they are not usable as a destination, so not as "general". Are they for sure to be counted with GPRs? I don't see a better alternative term for the real general registers. Integer registers are not the best substitute for GPR as eg. SP is (usually) a special purpose data integer register (and zero is an integer).. comp.arch (talk) 17:04, 23 May 2014 (UTC)

Xilinx Spartan

I seem to have some doubts about the claim that the Xilinx Spartan happens to have 1 GPR and 3 FP registers. As an FPGA, any number of registers can be instantiated within the limits of the hardware as part of a design, and the design need not be a processor to begin with. Rarkenin (talk) 10:32, 20 April 2016 (UTC)

ARM32 description

This partly ties in with what was said previously about the 6502 stack pointer register but pertaining to ARM chips. On at least the older incarnations (ARM2/ARM3/etc) R13 was only the stack pointer by convention. As far as the CPU is concerned it was general-purpose as there are no special stack instructions (AFAIK this is also true of the newer 32-bit-address-space chips provided they are operating in ARM (not Thumb) mode (see http://www.davespace.co.uk/arm/introduction-to-arm/registers.html). R14 can also be used as a general purpose register except when the BL (branch with link) instruction is used (which set it to the return address), so arguably there's 15 GPRs with the caveat about R14. On another note, I'm pretty sure R14 is also swapped out during a bank-switch. These assertions agree with what's written in https://wiki.riteme.site/wiki/ARM_architecture. I will modify the entry accordingly unless there are any objections? Thanks! 95.149.246.82 (talk) 23:07, 4 June 2016 (UTC)

Suboptimal constant register examples

"Constant registers hold read-only values such as zero, one, or pi." is in my opinion unnecessary and misleading, since in the beginning it might raise an impression, that these registers hold only single bit value constant, or at least that it's somehow useful to make these trivial values a constant; and then makes radical turnover that they can hold transcendental number constants. :) (to comment this edit reversal​) —Mykhal (talk) 00:37, 9 January 2018 (UTC)

It would seem that the processor architects who defined and implemented always-zero registers (the most common examples) on several different CPUs don't agree with your opinion that they're not useful. I don't see any implication of "single bit-value constant" as such registers are generally the same width as any of the GPRs. (If your GPR is 64 bits wide, to set it to zero you do have to clear all 64 bits!) Re your objection about transcendental numbers, it would be reasonable to add "an approximation of" to the mention of pi. Jeh (talk) 01:10, 9 January 2018 (UTC)

Categories of registers: Memory buffer register (MBR) vs. Memory data register (MDR)

Under the section "Categories of registers", the Internal registers "Memory buffer register (MBR)" and "Memory data register (MDR)" are linked to the same article. However, the linked article doesn't clearly differentiate between the two registers mentioned.

In the linked article (https://wiki.riteme.site/wiki/Memory_buffer_register), it seems to imply that both terms mean the same thing. The article states the following: "A memory buffer register (MBR) or memory data register (MDR) is the register in a computer's processor, or central processing unit, CPU, that stores the data being transferred to and from the immediate access storage."

Other source does seem to suggest that the two registered do mean the same thing.

Are you able to either just use one term if they are indeed the same thing? Or can you edit the document to clear up the differences? — Preceding unsigned comment added by Supmethods (talk • contribs) 16:33, 30 June 2018 (UTC)

CUDA

Whichever way you define and count registers, the CUDA table entries are complete nonsense. I'll have to come back from a desktop computer where I can make decent edits, but as it stands the CUDA row in the table is completely wrong. 85.255.235.215 (talk) 21:23, 8 January 2020 (UTC)

Figured out how to edit from my phone and replaced the CUDA entry with something sensible. Still need to reference the CUDA C Programming Guide though. 85.255.235.215 (talk) 21:43, 8 January 2020 (UTC).

"Stack pointer" vs. "stack register"

In this edit, the term "stack pointer" was replaced with "stack register", with the comment "his seems clearer to me, as this makes it harder to confuse it for a pointer pointing to a stack".

However, for better or worse, a Google Ngram for the two terms shows "stack pointer" used more than "stack register"; people used to the former term may be surprised by its absence.

"Stack pointer" could either mean "a pointer that points to a stack" or "a pointer that points *into* a stack" - in particular, to the top element of the stack; the latter is the correct interpretation.

I've reverted that change; discuss here. Guy Harris (talk) 22:36, 11 April 2024 (UTC)