Pipeline Hazards

• Structural Hazards
  • Occur when two different instructions need to use a part of the hardware at the same time
  • By breaking memory into I and D memory we eliminate one potential hazard
• Data hazard or a load hazard
  • I1: Load R3, R2, R1 (R3<-M[R2+R3])
  • I2: Add R4, R3, R5 (R4<-R3+R5)
  • I2 will be in ALUOP, I1 will be in mem
  • And the data in R3 will not be right
  • This is actually easy to detect with a little more hardware
  • And can be partially overcome by Data Forwarding
  • And can be partially overcome by the compiler filling the Load Delay Slot with another instruction.
  • Or the machine can just stall,
  • But it MUST NOT use the wrong value for R3
• Control Hazard
  • Consider the following code

         SUB R3 R2 R5   R3<-R2-R5
         BZR R3 R7      if (R3 == 0) PC<R7
         INST
    ...
    (R7) INST2
    	

  • I don't know the results of the subtraction until ALUOP
  • But by then I really want to have loaded the destination of my jump
  • This is a control hazard.
  • I need one more instruction after the branch before I can take the branch
  • This is called the branch delay slot
  • A compiler can fix this (move an instruction into this slot)
  • I can have a static prediction, forward jumps are if-then-else and are not taken, backward jumps are loops and are taken.
  • Modern hardware dynamically predicts branches, with a 90%+ accuracy
    • Load the suspected target
    • Execute this
    • Flush the pipeline if this is not right.
• As the pipeline length increases the potential harm of hazards also increases.