CS/COE 1541 term 2174 Quiz 1 (Solutions)

The numbers in [brackets] are the points the question is worth.

1. [2] What is a structural hazard?

It's when two instructions need to use the same hardware at the same time.

2. [4] List two possible ways to deal with structural hazards.

You could stall, letting one instruction go first; you could add more hardware so that there's enough
for all the instructions to use simultaneously.

3. [2] What is a data hazard?

It's when one instruction needs the data from a previous instruction, before the previous instruction
has finished executing.
4. [4] List two possible ways to deal with data hazards.

You could stall, waiting for the previous instruction to finish executing; you could add forwarding
hardware to let the second instruction get the data it needs earlier.

5. [2] What is a control hazard?

It's when you execute a conditional branch, and you don't know whether to go to the branch target or
to the next instruction.
6. [6] Why can control hazards be much worse for performance than the other two kinds of hazards?
Explain what can happen and give a small code example that demonstrates the problem. (Your
code doesn't have to be a perfect real MIPS program, just enough to demonstrate the issue.)

They can be worse because while structural and data hazards only stall one instruction, control hazards
could cause you to flush multiple instructions (especially when the pipeline is deeper).

What your example code looks like can vary, but as long as it makes sense, it's fine.

1
We added early branch decision and a branch predictor to our little MIPS CPU. We want to see if it
was worth the effort. We have a test suite of programs that we'll use to compare the performance of
the old and new CPUs. The branch instructions' average CPI (in the test suite) and clock cycle times
of the two CPUs are summarized below:

CPU Average Branch CPI Cycle Time

Old 6 4 x 10-8s
New 3 5 x 10-8s
Although there are only 5 pipeline stages, average CPIs can be higher than 5 because of stalls, as seen
here. Also notice that the extra circuitry needed for the branch predictor made the clock a little slower.

Here's our test suite's instruction mix, and the average CPIs of the other instruction classes.

Class ALU Loads Stores Branches

Percentage 60% 10% 10% 20%
Average CPI 3 6 5 (depends)

7. First you need to calculate the overall average CPI of the whole test suite for both CPUs. Please
circle/box your answer.
a. [2] What is the overall average CPI of the test suite for the old CPU? Show your math.
(3 x 60%) + (6 x 10%) + (5 x 10%) + (6 x 20%) = 1.8 + 0.6 + 0.5 + 1.2 = 4.1 cycles/instruction

b. [2] What is the overall average CPI of the test suite for the new CPU? Show your math.
(3 x 60%) + (6 x 10%) + (5 x 10%) + (3 x 20%) = 1.8 + 0.6 + 0.5 + 0.6 = 3.5 cycles/instruction

8. Now you can calculate the total execution time of the test suite for both CPUs. The test suite runs
8 x 108 instructions. Please circle/box your answer. It should be in seconds.
a. [2] What is the total execution time of the test suite for the old CPU? Show your math.
(8 x 108) x (4 x 10-8) x 4.1 = 131.2 seconds

b. [2] What is the total execution time of the test suite for the new CPU? Show your math.
(8 x 108) x (5 x 10-8) x 3.5 = 140 seconds

9. [2] Was adding the branch predictor a good idea? If yes, explain why. If no, explain what would
have to change to make it worthwhile.
No, not in this case. The branch predictor made the cycle length too long, and so performance
decreased even though the CPI was improved. In order for it to be worthwhile, the cycle length
would have to be improved. (You didn't need to show numbers, but if you did, the cycle length
would have to be about 4.5x108 s or shorter.)