Pipeline stall

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]

In a standard five-stage pipeline, during the decoding stage, the control unit will determine if the decoded instruction reads from a register that the instruction currently in the execution stage writes to. 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

Timeline

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
Further information: 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 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
gollark: If you try to use 1TB of RAM to store your infinite list of [1..], then your program will probably get killed.
gollark: Anyway, disregarding that, it technically *does* still have side effects, even ones within those contexts.
gollark: Haskell is impure because it has unsafePerformIO. QED.
gollark: But I don't think you can get around the heat issue because of annoying physical laws, even if you move computers onto photonics or something so they do not deal with pesky electricity.
gollark: Also, as I said (prompting this discussion), current computers take time to do things, draw electricity, emit EM radiation, etc.

See also

References
  1. Patterson, David A.; Hennessey, John L., Computer Organization and Design (4 ed.), Morgan Kaufmann, p. 338
  2. 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
  3. Patterson, David A.; Hennessey, John L., Computer Organization and Design (4 ed.), Morgan Kaufmann, p. 373
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.