Generic Superscalar Processor Models Issue queue based Lecture 11: Modern Superscalar FU Rename Wakeup D-cache Regfile bypass Fetch select Processor Models FU commit schedule Generic Superscalar Models, Issue execute Reservation based (already studied) Queue-based Pipeline, Multiple-Issue Design Reg FU D-cache Rename bypass Fetch ROB Wakeup FU commit select schedule execute Revised from Paracharla PhD thesis 1998 1 2 Compare Reservation Station and Issue Issue Queue Based Pipeline Queue Fetch->Rename->Issue->Reg-read-> Execute- Pipeline Stage Sequence >Writeback/Commit RS: IF -> REN -> REG/ROB->SCHD->… 1. IQ: IF -> REN -> SCHD -> REG ->… 2. Core structure: register mapping table Mapping Table vs. Status Table � Rename: translate architectural registers into RS: Status table chooses architectural register physical registers 1. or ROB Issue: send instruction out to register read and IQ: Always renames to a physical register then execution 2. Register file � Commit: Process mis-prediction/exception, update register renaming RS: Architectural register file stores 1. architectural states IQ: Physical register file; No architectural Why study? Used in Alpha 21264, MIPS R10000, Intel 2. register file! Mapping table determines P4 architectural states 3 4 Compare Reservation Station and Issue Register Mapping Table Queue Reservation Station Records the mapping Phy reg Arch reg RS: busy, fu, op, Qj, Qk, Vj, Vk from virtual, (virtual) 1. IQ: busy, fu, op, Pj, Pk, ReadyJ, ReadyK architectural 2. ROB registers to physical RS: Store register values registers 1. IQ: No register contents 2. Mapping is stored in R1 => P3 Pros and Cons of IQ: R2 => P10 RAM or CAM No copying between ROB and register R3 => P6 � memories R4 => P8 Efficient use of register � R5 => P12 Bad: Complex mapping table design … � 5 6 1
Register Renaming Examples Register Mapping Status Loop: Renamed dynamic instructions: R1 => P1 R1 => P1 P1=>R1 P1=>R1 P1=>R34 LW R2, 0(R1) … R2 => P2 R2 => P32 R2 => P33 R2 => P33 R2 => P33 ADD R2, R2, 1 BNE P2, P3, Loop R3 => P3 R3 => P3 R3 => P3 R3 => P3 R3 => P3 SW R2, 0(R1) LW P32, 0(P1) R4 => P4 R4 => P4 R4 => P4 R4 => P4 R4 => P4 ADD R1, R1, 4 ADD P33, P32, 1 R5 => P5 R5 => P5 R5 => P5 R5 => P5 R5 => P5 BNE R2, R3, LOOP SW R33, 0(P1) … … … … … ADD P34, P1, 4 At commit (possible sequence) BNE P34, P3, LOOP LW returns 100, R1=1000 … P1=4000 P1=4000 P1=4000 P1=4000 Assume at first BNE.rename, P2=200 P2=200 P2=200 P2=200 R1-R31 mapped to P1-P31, … … … … P32-P127 are free No change P32=100 P32=100 P32=100 P32=100 First BNE may be predicted P33=? P33=101 P33=101 P33=101 either correctly or not P34=4004 P34=4004 P34=4004 P34=4004 7 8 Commit and Rollback Program Execution Correctness � Only committed instructions write to register Rename point commit point and memory R1 => P1 R1 => P1 P1=>R1 P1=>R1 P1=>R34 Yes, from programmer’s viewpoint -- only R2 => P2 R2 => P32 R2 => P33 R2 => P33 R2 => P33 committed instructions’ register output R3 => P3 R3 => P3 R3 => P3 R3 => P3 R3 => P3 becomes visible R4 => P4 R4 => P4 R4 => P4 R4 => P4 R4 => P4 � Maintain correct data flow – a child instruction R5 => P5 R5 => P5 R5 => P5 R5 => P5 R5 => P5 always use the values from its parents … … … … … Yes, in renamed form, and not affected by speculative execution P1=4000 Commit successful: make the next mapping � Register/memory receives the value of last write P2=200 status as committed mapping status Yes, from programmer’s viewpoint -- … free the previous physical register P32=100 architectural mapping status is updated in P33=? program order Mis-prediction/exception: flush pipeline, P34=4004 flush the following mappings Note memory correctness is not affected 9 10 Mapping Table Design – MIPS R1000 Mapping Table Design – MIPS R1000 Mapping tables Branch stack How about precise exception? Current Mapping after Br4 Alternative PC4 � Cannot preserve every mapping status for every mapping Mapping after Br3 instruction Alternative PC3 Solution: record the change of mapping in Mapping after Br2 Alternative PC2 ROB Committed Mapping after Br1 Alternative PC1 mapping � ROB: Contains Dest Architectural Register, Committed mapping Renamed physical register, Old renamed physical register RAM-based structure: � On exception: rollback mapping one instruction by one instruction, four instructions per cycle � Automatically, parallel saving on branches at rename � Slow performance – but how frequent is � On mis-prediction: restore the previous mapping immediately, exception? flush pipeline, restart fetch at the alternative PC Note branch mis-prediction has fast recovery � On commit of branch instruction: make the corresponding mapping as the committed one � Stall if branch stack is full 11 12 2
Multiple Issue Pipelines Mapping Table Design – Alpha 21264 Valid bits Each pipeline stages accept k instructions – k- Arch. Reg # p0 1 1 issue processor p1 Arch. Reg # 1 0 Match and valid Arch. Reg # p2 0 1 � Alpha 21264 – 4-issue … � MIPS R1000 – 4-issue … � Intel P4 – 3-issue Arch. Reg # pk 1 1 committed current Memory structure must have multiple ports mapping mapping proportional to issue width! CAM structure � Associative searching on architecture register index, output physical register index (through an encoder) What if k instructions at rename have � One column represents one mapping, allocated to each dependence among them? Need Dependence instruction with register output at rename � One pair of valid bit changes per one dest renaming check logic! � Fast recovery even on exceptions 13 14 Dependence Check Logic Rs0 Rt0 Rd0 Rs1 Rt1 Rd1 Rs2 Rt2 Rd2 Rs3 Rt3 Rd3 No dependence mapping table check yet Ps0Ps1 Ps0Ps1 Ps0 Ps1 Ps0Ps1 Pd0 Pd1 Pd2 Pd3 Any change to the first renaming? What is the change to the second one? Third and forth ones? 15 3
Recommend
More recommend
