Pipeline stall: Difference between revisions
No edit summary Tag: Reverted |
Citation bot (talk | contribs) Alter: url. URLs might have been anonymized. | Use this bot. Report bugs. | Suggested by AManWithNoPlan | #UCB_CommandLine |
||
| (One intermediate revision by one other user not shown) | |||
| Line 4: | Line 4: | ||
==Details== |
==Details== |
||
In a standard [[classic RISC pipeline#The classic five stage RISC pipeline|five-stage pipeline]], during the [[classic RISC pipeline#Instruction decode|decoding stage]], the control unit will determine whether the decoded instruction reads from a register to which the currently executed instruction writes. If this condition holds, the control unit will stall the instruction by one clock cycle. It also stalls the instruction in the fetch stage, to prevent the instruction in that stage from being overwritten by the next instruction in the program.<ref>{{Citation|last1=Patterson|first1=David A|title=Computer organization and design: the hardware/software interface|date=2014|url=https://www.worldcat.org |
In a standard [[classic RISC pipeline#The classic five stage RISC pipeline|five-stage pipeline]], during the [[classic RISC pipeline#Instruction decode|decoding stage]], the control unit will determine whether the decoded instruction reads from a register to which the currently executed instruction writes. If this condition holds, the control unit will stall the instruction by one clock cycle. It also stalls the instruction in the fetch stage, to prevent the instruction in that stage from being overwritten by the next instruction in the program.<ref>{{Citation|last1=Patterson|first1=David A|title=Computer organization and design: the hardware/software interface|date=2014|url=https://www.worldcat.org/oclc/1130276006|pages=318|edition=5th|language=en|oclc=1130276006|access-date=2020-05-25|last2=Hennessy|first2=John L}}</ref> |
||
In a [[Von Neumann architecture]] which uses the program counter (PC) register to determine the current instruction being fetched in the pipeline, to prevent new instructions from being fetched when an instruction in the decoding stage has been stalled, the value in the [[program counter|PC register]] and the instruction in the fetch stage are preserved to prevent changes. The values are preserved until the instruction causing the conflict has passed through the execution stage.<ref name="hennessy_p373">{{citation | title= Computer Organization and Design | edition= 4 | last1= Patterson | first1= David A. | last2= Hennessy | first2= John L. | publisher= [[Morgan Kaufmann]] | page=373 }}</ref> Such an event is often called a '''bubble''', by analogy with an air bubble in a fluid pipe. |
In a [[Von Neumann architecture]] which uses the program counter (PC) register to determine the current instruction being fetched in the pipeline, to prevent new instructions from being fetched when an instruction in the decoding stage has been stalled, the value in the [[program counter|PC register]] and the instruction in the fetch stage are preserved to prevent changes. The values are preserved until the instruction causing the conflict has passed through the execution stage.<ref name="hennessy_p373">{{citation | title= Computer Organization and Design | edition= 4 | last1= Patterson | first1= David A. | last2= Hennessy | first2= John L. | publisher= [[Morgan Kaufmann]] | page=373 }}</ref> Such an event is often called a '''bubble''', by analogy with an air bubble in a fluid pipe. |
||
| Line 26: | Line 26: | ||
{{see|Classic RISC pipeline#Hazards}} |
{{see|Classic RISC pipeline#Hazards}} |
||
The below example shows a bubble being inserted into a [[classic RISC pipeline]], with five stages (IF = Instruction Fetch, ID = Instruction Decode, EX = Execute, MEM = Memory access, WB = Register write back). In this example, data available after the MEM stage (4th stage) of the first instruction is required as input by the EX stage (3rd stage) of the second instruction. Without a bubble, the EX stage (3rd stage) only has access to the output of the previous EX stage. Thus adding a |
The below example shows a bubble being inserted into a [[classic RISC pipeline]], with five stages (IF = Instruction Fetch, ID = Instruction Decode, EX = Execute, MEM = Memory access, WB = Register write back). In this example, data available after the MEM stage (4th stage) of the first instruction is required as input by the EX stage (3rd stage) of the second instruction. Without a bubble, the EX stage (3rd stage) only has access to the output of the previous EX stage. Thus adding a bubble resolves the time dependence without needing to propagate data backwards in time (which is impossible). |
||
{| align=center style="text-align:center" |
{| align=center style="text-align:center" |
||
Latest revision as of 03:43, 12 March 2023
 | This article needs additional citations for verification. (August 2012) |
In the design of pipelined computer processors, a pipeline stall is a delay in execution of an instruction in order to resolve a hazard.[1]
Details
[edit]In a standard five-stage pipeline, during the decoding stage, the control unit will determine whether the decoded instruction reads from a register to which the currently executed instruction writes. If this condition holds, the control unit will stall the instruction by one clock cycle. It also stalls the instruction in the fetch stage, to prevent the instruction in that stage from being overwritten by the next instruction in the program.[2]
In a Von Neumann architecture which uses the program counter (PC) register to determine the current instruction being fetched in the pipeline, to prevent new instructions from being fetched when an instruction in the decoding stage has been stalled, the value in the PC register and the instruction in the fetch stage are preserved to prevent changes. The values are preserved until the instruction causing the conflict has passed through the execution stage.[3] Such an event is often called a bubble, by analogy with an air bubble in a fluid pipe.
In some architectures, the execution stage of the pipeline must always be performing an action at every cycle. In that case, the bubble is implemented by feeding NOP ("no operation") instructions to the execution stage, until the bubble is flushed past it.
Examples
[edit]Timeline
[edit]The following is two executions of the same four instructions through a 4-stage pipeline but, for whatever reason, a delay in fetching of the purple instruction in cycle #2 leads to a bubble being created delaying all instructions after it as well.
|
|
| Normal execution | Execution with a bubble |
Classic RISC pipeline
[edit]The below example shows a bubble being inserted into a classic RISC pipeline, with five stages (IF = Instruction Fetch, ID = Instruction Decode, EX = Execute, MEM = Memory access, WB = Register write back). In this example, data available after the MEM stage (4th stage) of the first instruction is required as input by the EX stage (3rd stage) of the second instruction. Without a bubble, the EX stage (3rd stage) only has access to the output of the previous EX stage. Thus adding a bubble resolves the time dependence without needing to propagate data backwards in time (which is impossible).
| Bypassing backwards in time | Problem resolved using a bubble |
.svg)
|
.svg)
|
See also
[edit]References
[edit]- ^ Patterson, David A.; Hennessy, John L., Computer Organization and Design (4 ed.), Morgan Kaufmann, p. 338
- ^ Patterson, David A; Hennessy, John L (2014), Computer organization and design: the hardware/software interface (5th ed.), p. 318, OCLC 1130276006, retrieved 2020-05-25
- ^ Patterson, David A.; Hennessy, John L., Computer Organization and Design (4 ed.), Morgan Kaufmann, p. 373