Okay. So let's. We're, we're almost to the end here le, of, of control, hazards. Let's talk about why an instruction may not be dispatched every cycle. Well. Let's, let's think about forwarding and full bypassing. This is sometimes really expensive to add. If you are gonna bypass every location in your pipe, that may be expensive. So, we may still want to stop in certain cases. A good example of this is, if you go look at a modern day, something like your core I7 machine, they actually don't bypass between all the different functional units, from all the different locations, because they have, can execute about six instructions per cycle. And there, they have many stages in the depth of their pipe, so they'd have to basically be bypassing at a hundred different places for every new source off branch. So, what you typically will do, is you'll figure out, what are the common bypasses that are needed, are the common forwarding paths that are needed and you'll have those. And then some of the infrequently used ones, you just won't build. This will help with your cycle time, but hurt with your CPI. Loads, Can have a, or, typically have a 2-cycle latency. So we talked about this when we were talking about, load to use, and the instruction after the load. Cannot necessarily use the result, definitely cannot use the result because the in our five stage mix pipeline the result is not computed into the memory stage, so if you are in the SQ stage you would not have been able to get that even if you had bypassing out of the ends of the load end of, end of the load pipe or to the end of the memory stage. And one interesting thing is that the MIPS I Architecture. Actually defines low delay slots, very similar to what we have in What, what, what is what we had discussed with branch delay slots. So MIPS I had load delay slots, which were software visible, Slots that you had to fill and could solve, basically, this pipelining hazard. And the compiler would have to schedule some non-dependent instruction. So it was instruction which was not dependent on the load into that, that, that spot. This was ultimately removed out of the ISA and stalling was put back in cause as you went to different pipeline lanes and different micro-architectures this, this started to, to be onerous. And this is really one of the big problems with both load delay slots and branch delay slots is it's not very micro-architecture independent. So as you change to different micro architectures if you have let's say a pipeline length of five and it went to four, all of sudden maybe you didn't need that branch to lay slot or something, something like that. And. I wanted to sort of point out here is, this idea here, really is encapcilated in the name MIPS. It stands for microprocessor without interlocked pipeline stages. So, they really did not want to have interlocking here on something like the load to use of that, and later in MIPS two that, that was removed in pipeline interlocks were reintroduced. So, they, you know, we can all find mistakes that we have done and, and have changed it, but in the original MIPS 1ISA they had load delay slots. Another good reason why CPI might be greater than one is we have conditional branches which can cause bubbles. So this was all the control hazards we've been talking about up to this point, and you may have to kill the instructions if you don't have some sort of delay slots. Now, I wanted to point out here when we talk about cpi, and this is this note at the bottom of the slide, is that you really wanna think about Cpi from the perspective of a useable CPI, instead of How many instructions are executing. So if you are adding no-ops to your program, and the no-ops are not doing anything useful, that does not go into, that should not go into your useful CPI, calculation. Your machine might count that as valid instructions going down the pipe because you, it was software-invisible instructions, but that's not a good solution. What you should be computing in CPI, you should always be thinking about useful CPI, or CPI that's actually towards the end-goal of the program. Couple other control hazards That we need to talk about in this course are other things that can change your control flow of your program. And, those largely can fall into two different cases here. Exceptions and interrupts. And they're both related. And let's talk about what an exception is. So an exception is something where you have an instruction And the instruction does some operation, which is invalid or against what the intended use of machining. So, a good example of this, a couple good examples, is divide by zero. You take some value and divide it by zero. Well, on most computer architectures this is ill-defined or undefined. So you'll actually get an exception, which is a divide by zero error. And you can go try this out. You can go log in to your computers, and go run a little C program. Take some number, divide it by zero, you're going to get a div by zero error if you're running on Linux. And get something similar if you're running on Windows. And, Another good example of exceptions is, things like a, memory fault. Your trying to access your not allowed to go access. Some underflow and overflow exceptions in certain architectures. If like number precision goes out of, out of wack. If you have a, a, floating point number becomes too large or too small, and the floating point arithmetic can't handle the precision you'll sometimes get overflow and underflow exceptions. And then it interrupts our external things happening. And what's, So, something like a timer tick going off, or an IO device trying to wake up your processor, or do something to your processor. And why these are important, why these are control hazards, is these are unexpected things, sort of, coming into the, the instruction stream, and it's going to change. The subsequent instructions that are executing so, but it really is a control hazard flow. It's changing the program control flow. And we're going to be talking a lot more about exceptions and interrupts, later in this course, but I just wanted to get this idea across in this review so far that exceptions and interrupts are different types of control flow hazards.
