Let's move on to our second scheme.
So our second scheme if you go back to the, the earlier slide.
We said that you can either store pointers in the instruction queue and have pointers
in the reorder buffer. Or we can just store the values.
And if you go read the original reservation station paper by Thomas
[inaudible]. He actually stored the values in the
reservation station, or what we're calling the instruction queue and the reorder
buffer. Okay, so a couple, a couple things change
when you do this. One structure is missing.
First of all, there is no physical register file.
We removed that. We're going to store in flight
instructions in a merged reorder buffer physical register file effectively.
The second thing that's changed here is we no longer have a free list.
And we'll see in a minute why we don't need the free list.
But instead we're basically just going to use different reorder buffer and entries
to keep track of our free list. And we're going to have to modobot, modify
a bunch of stuff here. We're going to actually keep values in a
reorder buffer instead of a pointer. Our renaming tables can be modified, our
instruction ques now going to be able to keep track of actual data values.
And our physical register file as I said before has gotten merged into our reorder
buffer. For completeness here let's take a look at
the where things get red and green in the pipeline and one, one notable change I
wanted to say here is the architecture register file.
Which in previous architectures was only written.
We didn't do reading of it, except on rollback.
We now, actually read from it, because we might need to be able to go find some
canonical state in this architecture. So we, we add a R there to denote that.
Okay, so let's look at how we have to modify the reorder buffer.
Still looks like our reorder buffer from before.
We need to know for the same reason in the, pointer-based design.
We still need to know the architectural register number for the particular
instruction. So this is when we go to write to the
architectural register file. Where do we write to it?
Because we did renaming, so we have more physical registers.
We can't just have an identity map there anymore.
And now, we got rid of a lot of that other complexity we had, but we, we added a
bunch more bits to go do this. We now actually can store values in our
reorder buffer. So what this is, is instead of values
waiting in the physical register file to be committed, they're just gonna store,
they're just gonna stick around in the reorder buffer entry.
Which is, which is interesting. And so its gonna stick around here while
it's waiting, while its pending, and then it's actually gonna write to the
artificial register file when it gets the when it get committed.
Okay, so we also modify the instruction queue.
So this is gonna tell us where to go get the values, and we're gonna go execute.
It's also gonna store the values now. So what's, what's interesting about this
is, if you go back and look at the Thomas [inaudible] algorithm paper.
They broadcast, commits that are happening, and those commits end up in the
reservation station of the actual value. So we're actually going to store in these
two source operants here, the values. If we get a, instruction which commits.
If the instruction is pending, it's in flight, we can't go and just, get the
values. Because the value doesn't exist.
It's being calculated. And we have this dependent instruction
sitting waiting for something, [ah, ]. [Couch], so instead, if it's pending, our
source field. We're not going to store the value in
here, but we're going to store a, identifier into the reorder buffer.
And that, what it's going to do is it's going to name the exact instruction that
has to complete in order for this value to be ready to execute.
So if you think about this from sort of from the sort of Thomas [inaudible]
perspective. That these sort of broadcasts coming back.
And what this is going to allow us to do is say oh, there's a broadcast reorder
buffer entry, seven, just committed. Or actually we probably don't even need
that. We probably just need it to, get, stop
being, pending. We just need to get it, to be finished,
because it will then be deposited in the reorder buffer.
We can go pick that value out, at that point and store it here.
And then, we can basically, we have the other instructions that, that are renaming
and executing which, go and blow away that value.
But because we store the value here, we have the most up to date value for that
register and we know its no longer pending and its valid and ready to go, at least
this one, and we might have to wait for both of these to get ready in order for an
instruction to leave the instruction queue.
Okay. So the rename table, also changes a little
bit. Not, not, not as much as the other one of
the other structure. Structures.
It's still indexed you know by the register.
We're looking for register two, we'll say. It will tell us whether, Where, where to
go look for that. There is a couple different places where
it's going to tell us to go look for it. It's going to tell us either, it's in
flight, and it's gonna put it the, identifier into the reorder buffer.
So it's going to say when that value gets into the reorder buffer and the
instruction transitions to finish but maybe not yet committed. It's gonna tell
us to where to go get it. And that's important for subsequent
instructions that are going read the rename table to go find the value.
Or it's possible that the most up to date value is actually in the architecture
register file, and we need to go look there.
So, let's say the reorder buffer you haven't written let's say to register two
in a very long time. And lots of other instructions execute,
and the reorder buffer get's filled up with other things for other instructions
for different destination registers. It's very possible that the economical
place to go look for the value. Is in the, architectural register file and
we need to track that. So we sort of have two bits here.
It's sort of just say where to go look for it.
Either it's in the architectural register file or whether it's in flight, and then
if it's in flight we have to go look down here and if it's in flight that means that
and if P is, let's say one. It's actually in flight and if it's, it's
zero. Well it's in the reorder buffer waiting to
retire. This is just gonna tell us where to go to
find the actual value for subsequent instructions that want to go read the
rename table to go find the value. Okay, well, we'll, we'll move on and we'll
look at the eye chart here again. [laugh] and what's interesting about this
is we no longer have a free list. We got rid of that structure, so you don't
have to worry. Our renaming table instead of having
actual physical registers is going to have reorder buffer entries.
We're going, we'll call that physical register we'll basically merge our
physical registers and reorder buffer together.
And similar sorts of analogues happen too when something becomes free.
But it looks a little bit different. So when something becomes free, we're
going to actually. Change the, valid bits in the rename table
to a zero, and that's, that's effectively the same thing as becoming free.
And those, those analogs there between these two designs, they're, they're almost
exactly the same from that perspective, from a logical perspective.
But [inaudible] when. You be, you become free, you basically can
remove it from the, the table. So, so how do we do the mapping from the
architectural register to the physical register, yeah it could be random.
In, in this design its a little bit different because you're basically going
to re-pulling out of the, reorder buffer in order to some extent.
You're going to, your physical register number is going to be reorder, buffer
entry slot number. And because we want to retire in order,
we're basically going to allocate from that in order.
So it's not really random. It's just sort of the next reorder buffer
entry. Let's see what are the other points I
wanted to make here? Actually, okay.
I want to, I want to make a point. It's around, okay so, I think what I
[inaudible]. Okay, what I said was a little bit, little
bit confusing. So I want to, I want to clarify this.
When do you deallocate a reorder buffer entry?
It's a little bit different than deallocating a physical register entry.
You, you apply the same algorithm applied before.
When you go to actually commit the instruction to the architectural register
file. That's when it's becoming free.
It's basically stopping, stopping being used here.
That's a little bit different than the there's analogs to, to before.
But we're effectively moving it out of the reorder buffer into the architectural
register file. And at that point it becomes free.
So, I want to actually strike what I said before about it, it's exactly the same.
It's, it's different but subtly that when you go to write.
When you go to actually commit the instruction, you're moving it to the
access register file. And you've effectively deallocated that
reorder buffer entry, and you've updated the, the rename table.
So that's, that's, that's subtle. That's actually subtle there.
So we're actually, when it, when it commits, it stops, it stops being used.
This, which is different than a later instruction issue writing that.
So that is quite a bit different. Sorry about that.