Talk:Classic RISC pipeline

cleanup

WB,

You marked the article for improvement, but made no suggestions about what you'd like to see improved. Well, I can probably improve it, but I'd like some help. Specifically, I'd like to see, from you, some specific, constructive criticism of the article.

My guess is that you read the article and found that it didn't really explain the idea to you very well. Great. Tell me what questions you were left with. What didn't you understand? Do I need to define particular words? Did you not understand what the pipeline is for in the first place?

I did a quick reread, and I can see two things that I should do to fix the article up:

Add a diagram of the five stage pipeline.
Add a reference to Hennessy and Patterson: Computer Architecture, A Quantitative Approach, which is a textbook that explains most of this stuff.

Iain McClatchie 21:16, 22 August 2005 (UTC)[reply]

Hi, the article itself is written very well. Only thing I found was that, it might be a bit too complicated for a normal person to understand what's going on. I suggest some diagrams (like the Ukranian version), bit more wikifying. What I mean by not understanding is:

"With unsigned 32 bit wrapping arithmetic, 3000000000+3000000000=1705032704."

Although I understand this through the C++ experience, it might be appropriate to include an explanation of what unsigned 32 bit arithmetic is to a non-computer expert. Thanks -- WB 11:01, August 24, 2005 (UTC)

The Ukranian version pipeline diagrams are very nice. I'll see if I can get the same font, so I can modify them with an english "time" label on the bottom, but otherwise have them look identical.

This article is not the place to explain overflowing finite computer arithmetic. I agree that it's a useful thing to explain, and it doesn't appear that there is a Wikipedia entry for it to which to link.

Do you have any other specific criticisms?

Iain McClatchie 18:24, 25 August 2005 (UTC)[reply]

I think the article is reasonable at least. The biggest problem is the lack of an introduction, explaining what a pipeline is, then what a risc pipeline is and then what a classic risc pipeline is. This can be done very briefly with links to other wiki pages. I'm thinking something along the lines of: "a Classic RISC pipeline is a term in comuting that refers to the way data is send to the CPU. bladibladibla"

Martijn Hoekstra 20:14, 19 June 2006 (UTC)[reply]

Oppose name change (move)

WB,

I'd rather not move this article to "RISC pipeline". There are a lot of RISC processors out there, and many of the ones built since 1990 do not use this simple 5-stage pipeline. A "RISC pipeline" article should describe all those other pipeline structures as well. Such an article would not be able to cover the pipeline in the detail presented here. The detail presented here is valuable as an introduction to the complexity of CPU pipeline design.

The simple pipeline described in this page is still used by the simplest CPU designs, almost all of which would be called RISC.

I'm not sure a "RISC pipeline" article makes much sense, actually, since an overview of the pipeline organizations used by all RISC processors would basically cover all the pipeline organizations used by all processors. So, such an article would be better called "CPU pipeline", or pipeline (computer).

Other problems with delay slots

Very good write-up. Let me add another wrinkel. MIPS' conditional branches cannot be decided until the EX stage. One consequence of this is that the stages above the delay slot must be flushed upon branch. However the delay slot may have been stalled if it depends on a unfinished load, so care must be taken to not flush the wrong instruction. A pain in the neck to get right, not to mention the cycle-time impact on all the control logic. And if you want the unconditional branches to issue from the decode stage (for a lower branch penalty), then the control gets even more complicated -- Tommy Thorn, 2006-03-25

Branches in EX? Nope. In both early MIPS and early SPARC pipelines, the conditional branches were decided in the decode stage. That means the conditional branch recurrence was two cycles: instruction fetch, register read, branch decision, and instruction address mux. No bubbles are added to the pipeline. The R4000 pipeline added two bubbles for each taken branch.

In the Classic pipe, the delay slot cannot be stalled on a load hit. The load is in Access, the branch is in Execute, and the data from the load bypasses into Decode, to be used in the next Execute cycle.

Computing the branch condition in the decode stage definitely cuts into the time available for the instruction cache. The early machines had 40+ inverter-3 delays per clock cycle, which is what made this decision feasible.

Later, when we did superscalar machines, the delay slots which had seemed so clean before were a nuisance. I remember Mitch Alsup giving a presentation in 1990 on the Motorola 88000 ISA. He knew then that delay slots were a good short-term but bad long-term idea. Iain McClatchie 07:21, 31 March 2006 (UTC)[reply]

MEM vs. Access

This article calls the fourth pipeline step access, while the DLX article (DLX being an example of classic RISC pipeline implementation) calls the fourth step MEM - Memory access unit. Are both the same? --Abdull (talk) 14:27, 23 May 2008 (UTC)[reply]

Pipeline Diagram Incorrect?

I was reading this article to refresh my memory on data forwarding and am either confused or think there is a mistake in the pipeline diagram using bypass. The code being executed is not in the correct order in the pipeline (first instruction should be in the right most position) Does this make sense? — Preceding unsigned comment added by 63.124.79.253 (talk) 13:14, 25 August 2011 (UTC)[reply]

Decode in RISC

In the article it is saying that the early risc machines had not microcode. How about the modern risc architectures? Do they translate their instructions in their internal 'microoperations' like x86 does and is it done in the decode stage? What these mops are? If they are some another instructions encoded in the bits sequencies, and emitted in some buffer, then they also must be decoded. Right? It would be very nice if one writes about how is now, because articles tell only how it was in the very past. For example the article on arm arch. mention the same without-microcode initial design and says nothing how it is now. And what the hell that microcode is? Especially for risc? In the x86 mops are "risc-like", so what the translation in risc? Risc into risc? How that microcode is represented internally? Just another encoded bit seqencies, or something else? And then, what exactly decoding is: dispatching/routing/switching to the appropriate execution units the information about what to do and what with, OR this is translation of the stream of the one level machine instructions into the stream of another set internal machine instructions? Sorry for my noobiness and horrible english. 77.52.154.144 (talk) 19:33, 26 June 2013 (UTC) SphericalNanocodeInVacuum[reply]

Classic == Outdated?

It would be helpful if there was some discussion on whether "classic" is used to to denote outdated and how this article fits into a modern architectures and understanding of pipelining. — Preceding unsigned comment added by Indolering (talk • contribs) 23:04, 15 March 2021 (UTC)[reply]