This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles ??? This article has not yet received a rating on the project's importance scale.

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

Wen-Mei Hwo, Yale Patt, Michael Shebanow, about 1985, describe R10k style renaming and checkpoint repair.

Jim Smith and Andrew Pleszkun, about 1986, describe ROB, history file, future file.

Add these paper references to this page.

Iain McClatchie 20:38, 2 May 2005 (UTC)Reply[reply]

I think the Reorder Buffer part of the Architectural vs. physical registers section is out of place. It starts out ok, by defining Reorder Buffers, but then 5 more paragraphs follow with details that I think should be in their own section. It also includes a ton of un-introduced three letter acronyms, and people out of nowhere.

It should be moved or deleted, I'm leaning on deletion. Any objections?

WmEddie (talk) 04:49, 22 February 2011 (UTC)Reply[reply]

Register renaming and instruction reordering are very intricately linked; without one, the other is entirely pointless. Kevin Baas^talk 18:25, 23 February 2011 (UTC)Reply[reply]

(though if you use transfer-triggered architecture, barrel processing, or just write the code right in the first place, both are entirely useless -- and a collosal waste of circuit area.) Kevin Baas^talk 18:28, 23 February 2011 (UTC)Reply[reply]

@Kevin_Baas said "Register renaming and instruction reordering are very intricately linked; without one, the other is entirely pointless." This is a common misconception. Register renaming is useful even on microarchitectures that are in-order both wrt instruction start (issue) and completion (writeback). I will see if I can find a public non-trade-secret reference to such uarchs. A.Glew (talk) 01:04, 28 November 2018 (UTC)Reply[reply]

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

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

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

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