Computer Architecture: A Quantitative Approach, 4th Edition

Info iconThis preview shows pages 1–5. Sign up to view the full content.

View Full Document Right Arrow Icon
1 University of California, Berkeley College of Engineering Computer Science Division EECS Fall 1999 John Kubiatowicz Midterm II SOLUTIONS December 1, 1999 CS252 Graduate Computer Architecture Your Name: SID Number: Problem Possible Score 1 25 25 2 25 25 3 20 20 4 30 30 Total 100 100
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
2 [ This page left for π ] 3.14159265358979323846264338327950288419716939937510582097494 5
Background image of page 2
3 Question #1: Prediction 1a) Why does branch prediction work? Machine code tends to exhibit regularity (e.g. branch instructions that run for loops) that can be taken advantage of in the processor. Machine code is an inefficient representation of programs and thus it exhibits all the signs of a weak encode (such as predictability). 1b) What is the aliasing problem for branch predictors? Is aliasing always bad? Branch tables have limited sizes (essentially a cache of all history of all branches). Thus multiple branches map onto the same entry. Since tags are not stored to identify these conflicts and clear out the old entries, aliasing occurs. No, some aliasing can be beneficial if aliased branches exhibit similar behaviour (can improve cold start behaviour). 1c) How does the branch target buffer (BTB) help modern branch predictors? ( hint: we want to be able to remove all branch delay slots): Even if branch prediction predicts successfully that a branch will be taken, the branch address needs to be calculated and sent to the I$. Instead of stalling on all taken branches, the branch targets can be “cached” in the BTB so that the new PC is immediately available and so no stalling / branch delay slots are needed (except in the case where the calculated new PC mismatches with the new PC from the BTB). 1d) Draw the hardware for a gshare branch predictor. Why does this type of predictor generally perform better than an equivalent GAg branch predictor? Aliasing is reduced due to the xor hash, and since there tends to be more bad aliasing than good aliasing, the predictor does better. Branch PC Global Branch History ± 2 Bit CTR 2 Bit CTR 2 Bit CTR 2 Bit CTR 2 Bit CTR
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
4 1e) For correct performance, out-of-order processors must detect and resolve RAW, WAR, and WAW hazards between loads and stores to memory. Describe the hardware support for detecting these hazards and provide a short, pseudo-code description of the questions that must be asked before a load or store is released to the memory system. Assume no dependence speculation for the moment (conservative removal of hazards). The hardware support that is needed is a load-store buffer with one entry for each load and store in flight stored in program order which contains the address of the data location and a pointer to its ROB entry or functional unit. LOAD:
Background image of page 4
Image of page 5
This is the end of the preview. Sign up to access the rest of the document.

This homework help was uploaded on 01/29/2008 for the course CS 252 taught by Professor Kubiatowicz during the Fall '07 term at University of California, Berkeley.

Page1 / 16

Fall99-quiz2 - University of California Berkeley College of Engineering Computer Science Division EECS Fall 1999 John Kubiatowicz Midterm II

This preview shows document pages 1 - 5. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online