This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | Next revision Both sides next revision | ||
buzzword [2014/02/05 19:20] rachata |
buzzword [2014/02/12 19:20] rachata |
||
---|---|---|---|
Line 439: | Line 439: | ||
* Execute both paths | * Execute both paths | ||
* Can lead to wasted work | * Can lead to wasted work | ||
+ | |||
+ | |||
+ | ===== Lecture 11 (2/12 Wed.) ===== | ||
+ | |||
+ | * Call and return prediction | ||
+ | * Direct call is easy to predict | ||
+ | * Retun is harder (indirect branches) | ||
+ | * Nested calls make return easier to predict | ||
+ | * Can use stack to predict the return | ||
+ | * Indirect branch prediction | ||
+ | * These branches have multiple targets | ||
+ | * For switch-case, virtual function calls, jump tables, interface calls | ||
+ | * BTB to predict the target address - low accuracy | ||
+ | * History based: BTB + GHR | ||
+ | * Virtual program counter prediction | ||
+ | * Complications in superscalar processors | ||
+ | * Fetch? What if multiple branches are fetched at the same time? | ||
+ | * Logic requires to ensure correctness? | ||
+ | * Multi-cycle executions (Different functional units take different number of cycles) | ||
+ | * Instructions can retire out-of-order | ||
+ | * How to deal with this case? Stall? Throw exceptions if there are problems? | ||
+ | * Exceptions and Interrupts | ||
+ | * When they are handled? | ||
+ | * Why are some interrupts should be handled right away? | ||
+ | * Precise exception | ||
+ | * arch. state should be consistent before handling the exception/interrupts | ||
+ | * Easier to debug (you see the sequential flow when the interrupt occurs) | ||
+ | * Deterministic | ||
+ | * Easier to recover from the exception | ||
+ | * Easier to restart the processes | ||
+ | * How to ensure precise exception? | ||
+ | * Tradeoffs between each method | ||
+ | * Reorder buffer | ||
+ | * Reorder results before they are visible to the arch. state | ||
+ | * Need to presearve the sequential sematic and data | ||
+ | * What are the informatinos in the ROB entry | ||
+ | * Where to get the value from (forwarding path? reorder buffer?) | ||
+ | * Extra logic to check where the youngest instructions/value is | ||
+ | * Content addressible search | ||
+ | * A lot of comparators | ||
+ | * Different ways to simplify the reorder buffer | ||
+ | * Register renaming | ||
+ | * Same register refers to independent values (lacks of registers) | ||
+ | * Where does the exception happen (after retire) | ||
+ | * History buffer | ||
+ | * Update the register file when the instruction complete. Unroll if there is an exception. | ||
+ | * Future file (commonly used, along with reorder buffer) | ||
+ | * Keep two set of register files | ||
+ | * An updated value (Speculative), called fiture file | ||
+ | * A backup value (to restore the state quickly | ||
+ | * Double the cost of the regfile, but reduce the area as you don't have to use a content addressible memory (compared to ROB alone) | ||
+ | * Branch misprediction resembles Exception | ||
+ | * The difference is that branch misprediction is not visible to the software | ||
+ | * Also much more common (say, divide by zero vs. a mispredicted branch) | ||
+ | * Recovery is similar to exception handling | ||
+ | * Latency of the state recovery | ||
+ | * What to do during the state recovery | ||
+ | * Checkpointing | ||
+ | * Advantages? | ||
+ | |