pipeline hazards - courses · pipeline hazards (second edition: sections 6.4-6.6 fourth edition:...

Pipeline Hazards

(Second Edition: Sections 6.4-6.6 Fourth Edition: Sections 4.7, 4.8 from Dr. Andrea Di Blas’ notes

CMPE 110 – Spring 2011 – J. Ferguson

Outline

•  Structural hazards: lack of resources •  Data hazards: data dependencies between

instructions •  Control hazards: branches

8 - 2

CMPE 110 – Spring 2011 – J. Ferguson

Hazards

8 - 3

Hazards are situations that prevent the next instruction from moving through the pipeline

•  Structural Hazards are caused by conflicts in resource usage.

•  Data Hazards are caused by instructions that require results from a previous (uncompleted) instruction.

•  Control Hazards are caused by instructions that change the Program Counter.

CMPE 110 – Spring 2011 – J. Ferguson

Structural Hazards

•  Overlapping instructions requires the duplication of resources so that not all instruction combinations are possible.

•  The pipeline is said to have a structural hazard if some combinations of instructions can not be accommodated.

9 - 4

CMPE 110 – Spring 2011 – J. Ferguson

Example: Instructions and Data are in the same single-port memory.

9 - 5

CMPE 110 – Spring 2011 – J. Ferguson 9 - 6

When a structural hazard occurs the pipeline is stalled. The latter of the stages requiring the resource does not advance while the resource is used by the earlier instruction.

bubble

CMPE 110 – Spring 2011 – J. Ferguson

Stalls represented by a “bubble” in the pipeline

9 - 7

CMPE 110 – Spring 2011 – J. Ferguson

Data Hazards

•  Data hazards occur when an instruction reads data before it is written by a previous instruction.

•  Examples add $8, $7, $6 sub $9, $8, $5 ----------------- lw $7, 16($5) ori $8, $4, $7

9 - 8

CMPE 110 – Spring 2011 – J. Ferguson 9 - 9

The next 2 instructions after the sub will get the “old” value in $2 (assuming that written data into registers will be read in same cycle).

CMPE 110 – Spring 2011 – J. Ferguson

Forwarding or Bypassing

9 - 10

CMPE 110 – Spring 2011 – J. Ferguson

Actual Forwarding

9 - 11

CMPE 110 – Spring 2011 – J. Ferguson

Forwarding on DataPath

9 - 12

CMPE 110 – Spring 2011 – J. Ferguson

More Detail (Forwarding Unit)

9 - 13

CMPE 110 – Spring 2011 – J. Ferguson

Forwarding Unit logic

9 - 14

If((EX/MEM.Rdest = ID/EX.Rs) && EX/MEM.WB) Forward EX/MEM.ALUresult to Rs input of ALU

CMPE 110 – Spring 2011 – J. Ferguson

Why not always forward from EX/MEM buffer?

9 - 15

CMPE 110 – Spring 2011 – J. Ferguson

Summary of “forwarded” hazards •  “ALU to ALU” hazards: •  If

add $3, $4, $8 add $6, $3, $8 Take register value from the EX/MEM pipeline register

•  If add $3, $4, $8 a “non-dependent” instruction add $6, $3, $8 Take register value from the MEM/WB pipeline register

9 - 16

CMPE 110 – Spring 2011 – J. Ferguson

Store instruction data dependency

9 - 17

New register value become available cc4, not cc3

Forwarding doesn’t work for this instruction!

CMPE 110 – Spring 2011 – J. Ferguson

Load instruction data dependency must stall…

9 - 18

… and be forwarded!

CMPE 110 – Spring 2011 – J. Ferguson

What happens “in” the Bubble?

9 - 19

CMPE 110 – Spring 2011 – J. Ferguson

Hazard Detection Unit (or Pipeline Interlock)

9 - 20

The HDU checks if EX instruction is a load and the EX instruction destination register is source register in the ID instruction. If so, it stalls the IF and ID stages for one cycle.

CMPE 110 – Spring 2011 – J. Ferguson

Load Data Hazards adds a Clock Cycle to the Pipeline

•  How much does this slow down the computer? –  One extra clock cycle for each instruction –  Is that a lot?

•  Software solution: Whenever possible, reorder instructions so that the next instruction is not dependent on the destination of the Load instruction.

9 - 21

CMPE 110 – Spring 2011 – J. Ferguson

Example: Instruction Reordering

9 - 22

Loop addi $5, $5, 4 lw $8, 0($5)

add $7, $8, $9 sw $7, 0($4)

addi $4, $4, 4 bne $4, $10, Loop

Loop addi $5, $5, 4 lw $8, 0($5)

addi $4, $4, 4 add $7, $8, $9

sw $7, -4($4) bne $4, $10, Loop

CMPE 110 – Spring 2011 – J. Ferguson

Control Hazards

9 - 23

Control instructions may change the flow of the next instruction to be executed. We have that evaluation in the EX stage.

Simple solution is to stall the pipeline until branch resolved

CMPE 110 – Spring 2011 – J. Ferguson

Partial Solution: Resolve Branch Sooner

9 - 24

CMPE 110 – Spring 2011 – J. Ferguson

From 3 to 1 stage bubble

9 - 25

Must “flush” IF to get rid of bubble.

CMPE 110 – Spring 2011 – J. Ferguson

Second Improvement: Speculative Execution

9 - 26

Start on next instruction, flush only if needed

CMPE 110 – Spring 2011 – J. Ferguson

MIPS approach: Delayed Branch

•  Always execute the next instruction after the branch.

•  Compiler reorders instructions to put useful instruction after the branch (one that must be executed anyway).

•  If no useful instruction: put NOP after the branch.

9 - 27

CMPE 110 – Spring 2011 – J. Ferguson

Example of Delayed Branch

9 - 28

Loop addi $5, $5, 4 lw $8, 0($5)

addi $4, $4, 4 add $7, $8, $9

sw $7, -4($4) bne $4, $10, Loop

….

Loop addi $5, $5, 4 lw $8, 0($5)

addi $4, $4, 4 add $7, $8, $9 bne $4, $10, Loop

sw $7, -4($4) ….

CMPE 110 – Spring 2011 – J. Ferguson

Check our understanding

•  Allowing jumps, branches and ALU instructions to take fewer stages (and cycles) will increase performance under all circumstances.

•  Allowing some instructions to take fewer cycles does not help, because only one instruction will be executed per clock cycle.

•  Instead of trying to take fewer cycles, perhaps we can explore making the pipeline longer by the cycles shorter.

8 - 29

Observation: not all instructions need all five cycles of the pipeline. Which are correct if you ignore all hazards?