1 / 4

This is a control hazard – as opposed to data hazard we just examined

The Light at the End of the Tunnel – Doesn’t Mean You Died ! Part 3 - Branch Hazards – Easier! – 3/24/04. This is a control hazard – as opposed to data hazard we just examined Also called a branch hazard A successful conditional branch invalidates follow-on instructions

Download Presentation

This is a control hazard – as opposed to data hazard we just examined

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Light at the End of the Tunnel – Doesn’t Mean You Died! Part 3 - Branch Hazards – Easier! – 3/24/04 • This is a control hazard – as opposed to data hazard we just examined • Also called a branch hazard • A successful conditional branch invalidates follow-on instructions • Rather than stalling for each branch to see it is successful or not, assume it is not successful • Branch prediction: guess that the branch is NOT taken • If guess is correct, the we proceed full speed • If guess is wrong (branch taken), then the following instructions that are being fetched or decoded must be discarded. • The over head for successful branches take place only ½ of the time. • Discarding instructions: • Done much the same as in the data hazard stall case • But must now change 3 instructions in the IF, ID, and EX stages when the branch reaches the MEM stage • In the case of data hazard stalls we let nop’s “percolate” from the EX stage by inserting zeros for controls in the ID/EX register. • In this case we would have to flush the 3 following instruction dead in their tracks. In the next slide we see how to reduce this to one instruction.

  2. The Final Data Path “Tweak” – Reducing the Delay of Successful Branches • Move branch execution up earlier in the pipeline - See fig 6.30, p. 470 for the way it was. • Fewer instructions to be flushed. • Move branch decision to ID stage (was in MEM stage) • Check equality of registers in ID stage by taking XOR of registers and then ANDing of results. • The information for the target address calculation is available in the IF/ID register (in ID stage) – move the branch address adder from EX stage to ID stage. • Now on successful branch, there is only one instruction to be flushed, the one currently being fetched. • Instruction in IF stage is flushed by adding a new control line: IF.Flush • Zeros out the the instruction field in the IF/ID register – effectively making it a nop.

  3. Example of Impact of Successful Branch on the Pipeline EX/MEM–Mem–MEMWB stage  Fig. 6.50 Illustrates the “conservative” approach where 3 instructions must be flushed. In this case decision for branch made in MEM stage.

  4. Data path with the branch hazard feature Fig. 6.51 Note: the compare circuit (“=“ ) above is the selector of the PC MUX

More Related