Let's first look at the renamed table. So.
We're at the rename table. Or, we're actually gonna say we only have,
for, for clueless here, let's say we only have seven architectural registers.
But we're going to have let's say. Ten physi, or, eleven physical registers.
So we're gonna have more physical registers than actual registers in this
example. We start off and we say, Okay, well,
register one. If you want to go find architectural
register one, the values in physical register zero.
And we could basically just, you know, we just come up with some allocation.
And the circles mean that it's not pending.
It's not in flight in the pipe. That's just sort of the base case.
Everything is, the, the pipe has been relaxed.
Everything is, is allocated, and we just drew a basic allocation here at the
beginning. Now as we go to execute, some interesting
stuff starts to happen. The first thing that is going to happen
is, we are actually going to, here, issue this instruction, which writes to register
one. We need to rename this, at this point.
Register one will have to be named as something else.
So in this table here, if we look, we register, we rename register one to
physical register seven. Okay, that sounds good.
What happens next. Well we next sit here, and we try to
execute this instruction here, It says mall, and it goes to try to read register
one. When it goes to read register one though,
we can go look at the rename table and say, oh well that's actually in flight,
and it's in physical register seven. So if we go look over here, we can draw
this and say, oh that value is actually in physical register seven, and it's
currently not ready, maybe, and, But P4, the other input, register five, to do,
okay, yeah, register five got renamed to P4, is ready.
So it's ready to go. Okay, let's, one of the other interesting
things that happens here is we can see that as we go to allocate this, we have to
remove it from the free list. So this list here is the list of all the
free registers. We start off with four free registers and
we sort of narrow it down as we start to do rights.
At some point we run out. So I want to make an important note about
this is that when we run out of physical registers we're going to have to stall the
pipe, because we can't do any more renaming.
We can't issue more instructions at that point.
So that's, that's really, that's really important to realize that when you build
your machines you have to have enough physical registers that you don't run out
very often. Now, it's possible that you could still
run out. So let's say you have hundreds of in
flight instructions. And you only have, let's say, 64 physical
registers. You might still run out, But the
probability of that happening, my, might be relatively low.
And the, your utilization, and, you know, you sort of bake into this your CPI.
Your CPI may not be less than one, or may not be low.
So, you know, the probability of that actually happening.
You may not worry about it too much. Another cute little story here is there's
actually been some interesting bugs in processors around the free list.
So there were some alpha processors that actually leaked free list entries in their
register file. So what happened was if you ran a certain
piece of code for a long enough period of time all of a sudden this processor just
ground to a halt cause it was not able to allocate more physical registers and it
ran out. And ends up with fewer physical registers,
architectural registers, and the machine just stopped.
And this was a, sort of well-known bug in, in some of the early Alpha, I think this
was actually in the first, out of, I want to think where was this, I think this was
in the, 21264 had this problem. They, they fixed it.
And, they pulled those chips off the shelf.
And, you know, that's a, that's a really bad thing to, have happen, in your
processor. How embarrassing.
But as I said, if you run out, you're really not going to be able to issue more.
But in this case we made sure we had enough.
So we're not actually going to see any stalls.
And let's look at how things get on the free list here.
Cause that's a little bit interesting. In our reorder buffer, I said we had extra
fields. If you recall, we had the previous
physical register that this was allocated into.
So, if we go look, at this instruction, which is the first instruction, go to
execute that mull, R1 was in P0. So when that instruction commits, we
actually put p0 onto the free list. And we're going to look at a case in a
second why you can't do it earlier. Because it seems like you should be able
to basically de-allocate physical registers earlier.
You know, no one's probably gonna be reading that value.
Why can't you just, you know, get rid of it early?
But we'll look at in a second that a test case that, that, that's, that's a problem
with. Let's see any, any other fun insights
here? That's, that's about it, what I wanted to
get across from, from this diagram. As, as the code continues on we end up
with more and more free physical registers.
One thing one thing I did wanna just to walk through this, understand this a
little bit. Let's say we have this instruction here
which is our one, two, three, four. It's our last instruction that we execute.
Let's go see what it's doing here. So writes architecture register four, so
let's just store that in the reorder buffer cuz we don't know where to go to
the right. We had allocated p10 to that, and we did
that right here, when we actually issued it.