In this course, you will learn to design the computer architecture of complex modern microprocessors.
Control Hazards, Others
Loading...
來自 Princeton University 的課程
Computer Architecture
266 個評分
從本節課中
Cache Review
This lecture covers control hazards and the motivation for caches.
與講師見面
David WentzlaffAssociate Professor
Electrical Engineering
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.
