Part 5 – Superscalar & Dynamic Pipelining - An Extra Kicker! 5/5/04+

1. Part 5 – Superscalar & Dynamic Pipelining - An Extra Kicker! 5/5/04+ • Three major directions that simple pipelines of chapter 6 have been extended • If you thought chapter 6 was complicated you ain’t seen nothing yet! • But fear not Virginia – all we want here is an awareness of the leading edge! • … And yes there is a Santa Clause! • Three ideas: • Superpipelining • Superscalar • Dynamic pipelining • These are cool buzzwords for job interviews… especially if you know what they mean!

2. Super Pipelining • Means longer pipelines • Pipelining is parallel processing • Each pipeline stage is, in a sense, a processor in a parallel processing system • The more the stages, the more the parallelism, and consequently the greater the speedup. … you’re doing more things at the same time. • Ideally n stages means n instructions simultaneously executed. • We had 5 stages in chapter 6 – some modern processors have 8 • To take advantage of the increase of the number of stages, we have to re-balance the work-load in each stage.

3. Superscalar • In chapter 6 we had 5 stages in our pipeline • 5 way parallelism • One instructions was executed per stage • What if we executed more than one instruction per pipeline stage? • Gotta add more and “redundant” hardware • In our mundane washing machine example: this would mean having 3 washers and 3 dryers • Problem is to keep all the extra hardware busy • Now we could get get an instruction rate which exceeds the clock rate. • This is like exceeding the speed of light! • But fear not Virginia, it’s only an illusion! • Example see ==>

4. Example: Superscalar MIPS New stuff is in red Two instructions per clock cycle Two output ports from memory Two read ports from register file An extra write port for register file Another ALU

5. Dynamic Pipelining • The simple minded chapter 6 approach makes “downstream” instructions stall while a pipeline hazard is being resolved (stalled) even if they are independent of the hazard situation. • Let hardware detection of this situation allow the downstream instruction to execute during the resolution of the hazard. • Dynamic rescheduling of instruction execution in real time • In general can be used for: • Hiding memory latency • Avoid stalls that the compiler could not schedule around • Speculatively execute instructions while waiting for a hazard to be resolved • These are forms of parallelisms in the spirit of task switching in multiprogramming during I/O blocks • This makes hardware hard to debug because of branch prediction • More complicated pipeline control.