1. The ESW Paradigm Manoj Franklin & Guirndar S. Sohi 05/10/2002

2. Observations Large exploitable ILP, theoretically Close instructions dependent; parallelism possible further down stream Centralized resources is bad Minimizing comm cost is important

3. What about others? -Dataflow model + most general -unconventional PL paradigm -comm cost can be high -SS, VLIW (sequential) + temporal locality -large centralized HW -compiler too dumb -not scalable -ESW = dataflow + sequential

4. Design Goals Decentralized resources Minimize wasted execution Speculative memory address disambiguation realizability Replace large dynamic window with many small ones

5. How it works Basic window –Single entry, loop-free, call-free block –Equal, superset or subset of basic block Execute basic windows in parallel Multiple independent stages –Complete with branch prediction, L1 cache, reg file…etc.

6. Dist Inst Supply Optimization: Snooping on L2-L1 Cache traffic

7. Dist Inter-Inst Comm Observation: 1.Register use mostly within basic block 2.The rest in subsequent blocks Architecture: 1.dist. future file 2.create/use masks for dep. check

8. Dist DMem System Problem: 1.Addr. space large, can’t create/use mask 2.Need to maintain consistency between multiple copies Solution: ARB

9. ARB Q. What happens when ARB’s full? - Bits cleared upon commit - Restart stages when dependency violated - When load, forward values from ARB if already exists

10. Simulation Environment Custom simulator using MIPS R2000 pipeline Up to 2 inst fetch/decode/issued/ per IE Up to 32 inst per basic window 4K word L1 cache, 64KB L2 DM Cache (100% hit rate, what??) 3-bit counter branch prediction

11. Results Optimizations: 1.Moving up instruction 2.Expand basic window (in eqntott and expresso) Basic window <= basic block But is 100% cache hit rate reasonable?

12. Discussion Compare this to CMP? RAW? Does the trade-off strike a balance?

13. New Results (1) In order execution

14. New Results (2) Out of order execution