teaching machines

CS 352 Lecture 37 – Hazard Mitigation

December 12, 2016 by . Filed under cs352, fall 2016, lectures.

Dear students,

Last time we introduced the idea of pipelining, which allowed multiple instructions to progress through the processor at a time. But we saw some dangers that crept in. If this were politics, we would tell pipelining to apologize and resign. But we’re computer scientists, and we fix things rather than give up on them. Let’s walk through the issues we saw last time and talk about how to avoid them or lessen their impact.

First we saw data hazards. We looked at read-after-write, in which a later instruction relies on the result of an earlier instruction. If the earlier instruction hasn’t written back the result to the register file, the later instruction will read the wrong value. What can we do about it?

We also saw control hazards. When we have a branch instruction, there are two possible next instructions. (If we have mov pc, ?, there are a lot more than two choices!) Since we don’t know exactly what the program counter is going to be, we can’t schedule the next instruction in the pipeline. Is this a big deal? Yes, given that about 20% of instructions are branches! What do we do? Well, we have a few choices:

Next class we have a couple folks from Superion visiting to talk about FPGAs. So, this will be my last time at the front of the room. I just want to revisit what we’ve done this semester:

  1. We’ve looked at how we can tame electricity and switching technology to compute logical and arithmetic operations.
  2. We’ve examined how we can mix in time and memory to our devices so they execute not just one operation but a whole program.
  3. We’ve looked briefly at how we can connect up devices to our machine so they can pull input from the user and push output back.
  4. We’ve discussed mechanisms for making sure that this monster that we’ve built performs as fast as possible.

Why did we talk about all this stuff, which seems fairly removed from the activities of our internships and other classes? After all, critics of the computer-science-for-all initiatives argue that one does not need to understand how an engine works in order to drive across town. They may be right, but you are not just a driver, a user of a computer. You are making it do things it didn’t know how to do before you came along. For that to happen to its fullest, we have to crack open the hood.

Here’s your TODO list for next time:

See you next class!


P.S. Here’s the code we wrote together…