Talk:Register renaming

Renaming without pipeline descriptions
Initially I had thought that I could describe just the mechanics of renaming without pipeline descriptions. Didn't happen; those descriptions got large. At some point I will move those two pipeline descriptions into their own pages, like the Classic RISC Pipeline page. Before I do that I'd like to find better names for the renaming styles.

Better diagrams would be nice as well. I haven't figured out how to make them both compact and readable.

Finally, the introduction is a tough read. It's easy to write something short but it usually ends up either cryptic or wrong. The current version is cryptic.

Iain McClatchie

You removed the discussion of registers-for-speed and noted it (apparently) as a "factual error". I have to disagree. The growth in register count from ~3 in the 1970s to the hundreds in modern CPU's is specifically to take advantage of higher speed access, allowing one-cycle retiring. Perhaps I am misreading the check-in note, but if not I think it's reasonable to re-add the portion on performance.

Maury 23:55, 24 Feb 2004 (UTC)

Let me expand on my check-in note:

> Registers are small pieces of memory that can be accessed with almost zero > cost

I didn't understand precisely what "cost" meant.

> Registers are an important part of the CPU design,

I didn't think this added anything; you were working up to...

> but take up considerable room on the CPU design

No. Specifically, things like architectural register files in fast x86 designs are absolutely tiny. Issue/decode logic dominates.

> and are therefore "expensive".

No. Large numbers of registers in the ISA are "expensive" because you have to encode them, which means the instructions get large and awkward and chew up lots of instruction cache.

> One of the major goals in CPU design is to get the best use of the > registers for the lowest cost.

I've been part of two CPU designs, and at no time did anyone mention this as a goal. Never heard about it from any other CPU design teams either.

That said, adding architected registers to ISAs has been a point of several modern ISA designs. For high speed out-of-order designs, this is to give the compiler more names to expose more parallelism to the hardware. For embedded designs, it's gone both ways -- many ISAs went with 32 registers because that was the classic RISC style, and it fits nicely in a 32 bit instruction. Others (e.g. ARM Thumb) went with smaller numbers of registers (8 IIRC), trading exposed parallelism for packing density. I have not done a stack architecture, but I hear they are dense and give a fair number of registers too, at the cost of decoder complexity.

> functional units, a single one of which would represent a complete CPU > on it's own

Also false. Functional units refer to ALUs, FP multipliers or adders, or cache access pipes. The term is actually a bit vague, since it sometimes refers to a bunch of possible computations that share a writeback port to a central register file.

You had something in there about 20-way superscalar machines. You may have intended to refer to vector operations, but I didn't get that from context.

"Fast" these days comes down to getting values from one functional unit to another with nothing more than wire and mux delays. This can be done with values that go through memory, but the hardware to figure out the aliasing and get this right is much larger and more power hungry than the hardware to figure out forwarding from register names.

I'm not sure how to write this accurately and concisely, but saying that putting in lots of registers is good because they're fast is just not right.

I do appreciate your interest, and I readily acknowledge that my writing is not the best and can be improved.

Iain McClatchie

history buffer
The description of a "history buffer" in this register renaming article sounds very different from the description of a "history buffer" in the branch predictor article. Does one or the other of these articles need to be adjusted to give a correct description of a history buffer? Or are there really two very different circuits (perhaps in different locations in the same CPU) that happen to have the name "history buffer"? (Is there maybe some other phrase we could use for one or the other or both to distinguish them?) --DavidCary (talk) 20:27, 10 December 2015 (UTC)


 * Like any other discipline, computer architecture is full of terms that have multiple definitions that are disambiguated by context. The term "history buffer" is used both branch prediction and register renaming (among others). As such, there's no need to edit anything to give either topic exclusive use of the term. L9G45AT0 (talk) 03:39, 29 July 2016 (UTC)

comp.arch posts
It looks like some of this article is paraphrased from some of my comp.arch posts. Sometimes just changing "I" to "Andy Glew". Thanks, but...

Probably there should be references to such material, either via the Internet Archive (which past experience shows wikipedia dislikes) or possibly to publication in "Internet Nuggets" in Computer Architecture news. The latter is more acceptable to pseudo-academics, although CAN is a non-refereed journal.

Else wikipedia will inevitably remove such content.

--A.Glew (talk) 22:53, 27 November 2018 (UTC)


 * If it's paraphrased, and a reference is made to a comp.arch post, that'll probably be acceptable to enough not to cause it to be Obviously Unreliable or whatever. Using Template:Cite newsgroup, and pointing to Google Groups, would work; the fact that the template exists suggests that USENET isn't inherently an unreliable source. Guy Harris (talk) 00:57, 28 November 2018 (UTC)