CS 152 Computer Architecture and Engineering. Lecture 14 - Advanced Superscalars

Size: px

Start display at page:

Download "CS 152 Computer Architecture and Engineering. Lecture 14 - Advanced Superscalars"

Preston Maxwell
6 years ago
Views:

1 CS 152 Comuter Architecture and Engineering Lecture 14 - Advanced Suerscalars Krste Asanovic Electrical Engineering and Comuter Sciences University of California at Berkeley htt:// htt://inst.eecs.berkeley.edu/~cs152 Last time in Lecture 13 Register renaming removes WAR, WAW hazards Instruction execution divided into four major stages: Instruction Fetch, Decode/, Execute/Comlete, Commit Control hazards are serious imediment to suerscalar erformance Dynamic branch redictors can be quite accurate (>95%) and avoid most control hazards Branch History Tables (BHTs) just redict direction (later in ieline) Just need a few bits er entry (2 bits gives hysteresis) Need to decode instruction bits to determine whether this is a branch and what the target address is 3/17/2009 CS152-Sring!09 2

2 Dynamic Branch Prediction learning based on ast behavior Temoral correlation The way a branch resolves may be a good redictor of the way it will resolve at the next execution Satial correlation Several branches may resolve in a highly correlated manner (a referred ath of execution) 3/17/2009 CS152-Sring!09 3 Branch Prediction Bits Assume 2 BP bits er instruction Change the rediction after two consecutive mistakes! take wrong taken taken taken take right taken taken take right taken taken take wrong taken BP state: (redict take/ take) x (last rediction right/wrong) 3/17/2009 CS152-Sring!09 4

3 Branch History Table Fetch PC 0 0 I-Cache k BHT Index 2 k -entry BHT, 2 bits/entry Instruction Ocode offset + Branch? Target PC Taken/ Taken? 4K-entry BHT, 2 bits/entry, ~80-90% correct redictions 3/17/2009 CS152-Sring!09 5 Exloiting Satial Correlation Yeh and Patt, 1992 if (x[i] < 7) then y += 1; if (x[i] < 5) then c -= 4; If first condition false, second condition also false History register, H, records the direction of the last N branches executed by the rocessor 3/17/2009 CS152-Sring!09 6

4 Two-Level Branch Predictor Pentium Pro uses the result from the last two branches to select one of the four sets of BHT bits (~95% correct) 0 0 Fetch PC k 2-bit global branch history shift register Shift in Taken/ Taken results of each branch Taken/ Taken? 3/17/2009 CS152-Sring!09 7 Limitations of BHTs Only redicts branch direction. Therefore, cannot redirect fetch stream until after branch target is determined. Correctly redicted taken branch enalty Jum Register enalty A PC Generation/Mux P Instruction Fetch Stage 1 F Instruction Fetch Stage 2 B Branch Address Calc/Begin Decode I Comlete Decode J Steer Instructions to Functional units R Register File Read E Integer Execute UltraSPARC-III fetch ieline Remainder of execute ieline (+ another 6 stages) 3/17/2009 CS152-Sring!09 8

5 Branch Target Buffer IMEM k redicted target BPb Branch Target Buffer (2 k entries) PC target BP BP bits are stored with the redicted target address. IF stage: If (BP=taken) then npc=target else npc=pc+4 later: check rediction, if wrong then kill the instruction and udate BTB & BPb else udate BPb 3/17/2009 CS152-Sring!09 9 Address Collisions Assume a 128-entry BTB target 236 BPb take What will be fetched after the instruction at 1028? BTB rediction = 236 Correct target = Jum Add... Instruction Memory! kill PC=236 and fetch PC=1032 Is this a common occurrence? Can we avoid these bubbles? 3/17/2009 CS152-Sring!09 10

6 BTB is only for Control Instructions BTB contains useful information for branch and jum instructions only! Do not udate it for other instructions For all other instructions the next PC is PC+4! How to achieve this effect without decoding the instruction? 3/17/2009 CS152-Sring!09 11 Branch Target Buffer (BTB) I-Cache PC 2 k -entry direct-maed BTB (can also be associative) Entry PC Valid redicted target PC k = match valid target Kee both the branch PC and target PC in the BTB PC+4 is fetched if match fails Only taken branches and jums held in BTB Next PC determined before branch fetched and decoded 3/17/2009 CS152-Sring!09 12

7 Consulting BTB Before Decoding 132 Jum 100 entry PC 132 target 236 BPb take 1028 Add... The match for PC=1028 fails and is fetched! eliminates false redictions after ALU instructions BTB contains entries only for control transfer instructions! more room to store branch targets 3/17/2009 CS152-Sring!09 13 Combining BTB and BHT BTB entries are considerably more exensive than BHT, but can redirect fetches at earlier stage in ieline and can accelerate indirect branches (JR) BHT can hold many more entries and is more accurate A PC Generation/Mux BHT in later ieline stage corrects when BTB misses a redicted taken branch BTB BHT P Instruction Fetch Stage 1 F Instruction Fetch Stage 2 B Branch Address Calc/Begin Decode I Comlete Decode J Steer Instructions to Functional units R Register File Read E Integer Execute BTB/BHT only udated after branch resolves in E stage 3/17/2009 CS152-Sring!09 14

8 Uses of Jum Register (JR) Switch statements (jum to address of matching case) BTB works well if same case used reeatedly Dynamic function call (jum to run-time function address) BTB works well if same function usually called, (e.g., in C++ rogramming, when objects have same tye in virtual function call) Subroutine returns (jum to return address) BTB works well if usually return to the same lace! Often one function called from many distinct call sites! How well does BTB work for each of these cases? 3/17/2009 CS152-Sring!09 15 Subroutine Return Stack Small structure to accelerate JR for subroutine returns, tyically much more accurate than BTBs. fa() { fb(); } fb() { fc(); } Push call address when function call executed fc() { fd(); } Po return address when subroutine return decoded &fd() &fc() &fb() k entries (tyically k=8-16) 3/17/2009 CS152-Sring!09 16

9 Misredict Recovery In-order execution machines: Assume no instruction issued after branch can write-back before branch resolves Kill all instructions in ieline behind misredicted branch Out-of-order execution? Multile instructions following branch in rogram order can comlete before branch resolves 3/17/2009 CS152-Sring!09 17 In-Order Commit for Precise Excetions In-order Out-of-order In-order Fetch Decode Reorder Buffer Commit Kill Inject handler PC Kill Execute Kill Excetion? Instructions fetched and decoded into instruction reorder buffer in-order Execution is out-of-order (! out-of-order comletion) Commit (write-back to architectural state, i.e., regfile & memory, is in-order Temorary storage needed in ROB to hold results before commit 3/17/2009 CS152-Sring!09 18

10 Branch Misrediction in Pieline Inject correct PC Branch Prediction Kill Kill Branch Resolution Kill PC Fetch Decode Reorder Buffer Commit Comlete Execute Can have multile unresolved branches in ROB Can resolve branches out-of-order by killing all the instructions in ROB that follow a misredicted branch 3/17/2009 CS152-Sring!09 19 Recovering ROB/Renaming Table Table r 1 t t vv t t vv Snashots Register File r 2 Ptr 2 next to commit rollback next available Ptr 1 next available Reorder buffer Ins# use exec o 1 src1 2 src2 d dest data Load Unit FU FU FU Store Unit Commit < t, result > Take snashot of register rename table at each redicted branch, recover earlier snashot if branch misredicted 3/17/2009 CS152-Sring!09 20 t 1 t 2.. t n

11 Seculating Both Directions An alternative to branch rediction is to execute both directions of a branch seculatively resource requirement is roortional to the number of concurrent seculative executions only half the resources engage in useful work when both directions of a branch are executed seculatively branch rediction takes less resources than seculative execution of both aths With accurate branch rediction, it is more cost effective to dedicate all resources to the redicted direction 3/17/2009 CS152-Sring!09 21 CS152 Administrivia Quiz 3, Thursday March 19, Virtual Memory 3/17/2009 CS152-Sring!09 22

12 Data in ROB Design (HP PA8000, Pentium Pro, Core2Duo) Reorder buffer Register File holds only committed state Ins# use exec o 1 src1 2 src2 d dest data t 1 t 2.. t n Load Unit FU FU FU Store Unit Commit < t, result > On disatch into ROB, ready sources can be in regfile or in ROB dest (coied into src1/src2 if ready before disatch) On comletion, write to dest field and broadcast to src fields. On issue, read from ROB src fields 3/17/2009 CS152-Sring!09 23 Unified Physical Register File (MIPS R10K, Alha 21264, Pentium 4) r 1 r 2 t i t j Snashots for misredict recovery t 1 t 2. t n Reg File Table Load Unit FU FU FU Store Unit (ROB not shown) < t, result > One regfile for both committed and seculative values (no data in ROB) During decode, instruction result allocated new hysical register, source regs translated to hysical regs through rename table Instruction reads data from regfile at start of execute (not in decode) Write-back udates reg. busy bits on instructions in ROB (assoc. search) Snashots of rename table taken at every branch to recover misredicts On excetion, renaming undone in reverse order of issue (MIPS R10000) 3/17/2009 CS152-Sring!09 24

13 Pieline Design with Physical Regfile Branch Prediction kill kill Branch Resolution kill kill Out-of-Order Udate redictors In-Order PC Fetch Decode & Reorder Buffer Commit In-Order Physical Reg. File Branch Unit Execute ALU MEM Store Buffer 3/17/2009 CS152-Sring!09 25 D$ Lifetime of Physical Registers Physical regfile holds committed and seculative values Physical registers decouled from ROB entries (no data in ROB) ld r1, (r3) add r3, r1, #4 sub r6, r7, r9 ld r6, (r1) add r6, r6, r3 st r6, (r1) ld r6, (r11) ld, (Px) add,, #4 sub, Py, Pz add,, ld, () add,, st, () ld P7, (Pw) When can we reuse a hysical register? When next write of same architectural register commits 3/17/2009 CS152-Sring!09 26

14 Physical Register Management R0 R1 R2 R3 R4 R5 R6 R7 ROB Table P7 P7 Pn Physical Regs <R6> <R7> <R3> <R1> use ex o 1 PR1 2 PR2 Rd LPRd PRd ld r1, 0(r3) add r3, r1, #4 sub r6, r7, r6 ld r6, 0(r1) (LPRd requires third read ort on Table for each instruction) 3/17/2009 CS152-Sring!09 27 Physical Register Management R0 R1 R2 R3 R4 R5 R6 R7 ROB Table P7 P7 Pn Physical Regs <R6> <R7> <R3> <R1> use ex o 1 PR1 2 PR2 Rd LPRd PRd x ld P7 r1 ld r1, 0(r3) add r3, r1, #4 sub r6, r7, r6 ld r6, 0(r1) 3/17/2009 CS152-Sring!09 28

15 Physical Register Management R0 R1 R2 R3 R4 R5 R6 R7 ROB Table P7 P7 Pn Physical Regs <R6> <R7> <R3> <R1> use ex o 1 PR1 2 PR2 Rd LPRd PRd x ld P7 r1 x add r3 P7 ld r1, 0(r3) add r3, r1, #4 sub r6, r7, r6 ld r6, 0(r1) 3/17/2009 CS152-Sring!09 29 Physical Register Management R0 R1 R2 R3 R4 R5 R6 R7 ROB Table P7 P7 Pn Physical Regs <R6> <R7> <R3> <R1> use ex o 1 PR1 2 PR2 Rd LPRd PRd x ld P7 r1 x add r3 P7 x sub r6 ld r1, 0(r3) add r3, r1, #4 sub r6, r7, r6 ld r6, 0(r1) 3/17/2009 CS152-Sring!09 30

16 Physical Register Management R0 R1 R2 R3 R4 R5 R6 R7 ROB Table P7 P7 Pn Physical Regs <R6> <R7> <R3> <R1> use ex o 1 PR1 2 PR2 Rd LPRd PRd x ld P7 r1 x add r3 P7 x sub r6 x add r3 ld r1, 0(r3) add r3, r1, #4 sub r6, r7, r6 ld r6, 0(r1) 3/17/2009 CS152-Sring!09 31 Physical Register Management R0 R1 R2 R3 R4 R5 R6 R7 ROB Table P7 P7 Pn Physical Regs <R6> <R7> <R3> <R1> use ex o 1 PR1 2 PR2 Rd LPRd PRd x ld P7 r1 x add r3 P7 x x sub add r6 r3 x ld r6 ld r1, 0(r3) add r3, r1, #4 sub r6, r7, r6 ld r6, 0(r1) 3/17/2009 CS152-Sring!09 32

17 Physical Register Management R0 R1 R2 R3 R4 R5 R6 R7 ROB Table P7 <R1> <R6> <R7> P7 <R3> <R1> Pn Physical Regs use ex o 1 PR1 2 PR2 Rd LPRd PRd x x ld P7 r1 x add r3 P7 x sub r6 x add r3 x ld r6 ld r1, 0(r3) add r3, r1, #4 sub r6, r7, r6 ld r6, 0(r1) Execute & Commit 3/17/2009 CS152-Sring!09 33 Physical Register Management R0 R1 R2 R3 R4 R5 R6 R7 ROB Table P7 <R1> <R3> <R6> <R7> P7 <R3> Pn Physical Regs P7 use ex o 1 PR1 2 PR2 Rd LPRd PRd x x ld P7 r1 x x add r3 P7 x sub r6 x add r3 x ld r6 ld r1, 0(r3) add r3, r1, #4 sub r6, r7, r6 ld r6, 0(r1) Execute & Commit 3/17/2009 CS152-Sring!09 34

18 Reorder Buffer Holds Active Instruction Window (Older instructions) ld r1, (r3) add r3, r1, r2 sub r6, r7, r9 ld r6, (r1) add r6, r6, r3 st r6, (r1) ld r6, (r1) (Newer instructions) Commit Execute Fetch ld r1, (r3) add r3, r1, r2 sub r6, r7, r9 ld r6, (r1) add r6, r6, r3 st r6, (r1) ld r6, (r1) Cycle t Cycle t + 1 3/17/2009 CS152-Sring!09 35 Suerscalar Register Renaming During decode, instructions allocated new hysical destination register Source oerands renamed to hysical register with newest value Execution unit only sees hysical register numbers Inst 1 O Dest Src1 Src2 O Dest Src1 Src2 Inst 2 Udate Maing Write Ports Read Addresses Table Read Data Register O PDest PSrc1 PSrc2 3/17/2009 CS152-Sring!09 36 O Does this work? PDest PSrc1 PSrc2

19 Suerscalar Register Renaming Inst 1 O Dest Src1 Src2 O Dest Src1 Src2 Inst 2 Udate Maing Must check for RAW hazards between instructions issuing in same cycle. Can be done in arallel with rename looku. O Write Ports Read Addresses Table Read Data PDest PSrc1 PSrc2 O =? =? PDest PSrc1 PSrc2 Register MIPS R10K renames 4 serially-raw-deendent insts/cycle 3/17/2009 CS152-Sring!09 37 Acknowledgements These slides contain material develoed and coyright by: Arvind (MIT) Krste Asanovic (MIT/UCB) Joel Emer (Intel/MIT) James Hoe (CMU) John Kubiatowicz (UCB) David Patterson (UCB) MIT material derived from course UCB material derived from course CS252 3/17/2009 CS152-Sring!09 38

CS 152 Computer Architecture and Engineering. Lecture 15 - Advanced Superscalars

CS 152 Computer Architecture and Engineering. Lecture 15 - Advanced Superscalars CS 152 Comuter Architecture and Engineering Lecture 15 - Advanced Suerscalars Krste Asanovic Electrical Engineering and Comuter Sciences University of California at Berkeley htt://www.eecs.berkeley.edu/~krste