 Now we're going to start looking at control hazards. Control hazards are actually not too different from data hazards. In this case, we have an instruction, a branch instruction, that may decide to change the expected value of our program counter. But it does this relatively late in the pipeline, whereas normally we're updating the value of that program counter every cycle. So this is another example of a read-after-write hazard, where we need to read the value out of our program counter, but the branch instruction won't have written that data back until the fourth cycle. So our problem is that our branches take a long time to compute their results. They won't actually tell us what our next instruction is until the fourth cycle of our pipeline. If you think about it, our branch has to take the values out of two registers, does that in cycle two, in cycle three it compares them, then in cycle four we finally know whether or not we want to take that branch so we can finally update the program counter. We've got a couple different ways of solving this problem. We could just add some know-op instructions. We could just wait for the branch instruction to complete before we even begin running another instruction. This works, it's effective, but it's not very efficient. We'd have to add three know-ops after every branch in our code. That's three cycles that we're just sitting around doing nothing. So we'd like to find something better. Well, one thing that we can do is that we could move our branch hardware to stage two. Turns out comparing for equality is actually really, really easy. If you want to know if two bits are equal, we can take the XOR of them. If the results of the XOR are zero, then those two bits were the same. If we get a one out, then they're different. So we can apply an XOR to every pair of bits in both of our registers. Take the results of those and stick them into a NOR gate. The NOR gate will then tell us whether or not those two values were actually equal. So that will give us a really quick and easy way to check for equality so that we can then go back and update our program counter in the second cycle. But we still wanted to read in a new instruction in that cycle. So we'll still have to add in one know-op. Only having one know-op is way better than having three, but it's still this empty wasted cycle. So we're going to consider, well, what if we just run an instruction in there? That's what we're going to be looking at for a while. What can we do with that one empty cycle? What can we stick in there that can potentially improve the performance of our processor?