|This is the talk page for discussing improvements to the Processor register article.|
|WikiProject Computing / Hardware||(Rated C-class, High-importance)|
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
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
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)
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://en.wikipedia.org/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)
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)