In order issue.
Out of order or excuse me. In order front end, out of order issue.
Out of order write back. And in order commence.
So, the middle portion of the pipe here is all out of order.
And then finally, we commit an order and we fetch an order.
So this has all of those structures that we had before.
It's sort of the union of everything. We have, issue Q.
We have future store buffer, reorder buffer, physical register file.
The scoreboard, an architectural register file.
This requires us to have everything. And we can start thinking about what this
does to performance. So, I'm gonna, I'm gonna push through here
because I only have two more slides and, the state.
We get lost otherwise. Okay.
So. Let's, let's see some interesting things
happening here. So we have out of order issue.
So we can see this add here issuing before this other before this multiply.
That's pretty cool. Ignore this bottom for a second here.
We have that same problem sort of showing up here.
We have this right happening, but even an out-of-order issue processor.
This, this should be able to get pulled back, as I said before.
But it doesn't, because at this point you'd have a, right hazard, you'd have a
hazard on, on the right back of the register file.
Something similar if you try to issue here, you'd be issuing two instructions at
the same time. So, so this starts to be a problem.
So, it actually ends up being pulled out. Interestingly enough the performance of
this, is, is not a whole better than what we had before If you sort of like cut it
here at fifteen cycles, the commit gets pushed out far because you have to commit
in order. But this fixes a lot of problems that we
had in the in order fetch, out of order, out of order, out of order.
Because we can have, precise exceptions at the end of a pipe.
We can have out of order issue, out of order execute.
We could still do in order fetch because, that's kind of symantics of programs.
So, Let's, let's take a look at let's say we had the ability to do double issue but
not double execute. How does this change?
We actually, if I change this to this diagram.
And as you can see here we actually have I here and I here in the same time period.
So we pull that back one and that, that, you would think that would actually help.
But, you know so we don't, we don't have a right conflict everything is still kind of
okay here. But the commit still happens at the same
time. So thats not always, always as good as you
think. In reality what you want to start thinking
about is having, out of order and with. So here we have a, out of order two wide
superscalar. What we showed before in order fetch, out
of order issue out of order right back and in order commit.
And we can see is we are actually fetching two instructions at a time, decoding two
instructions at a time. Issuing two instructions at a time and
this, this can actually help a little bit but you still have problems.
So here we're just going to have. We can only, we'll build an issue two but
we're not going to have two ALU's, we're going to have the same sort of back end of
the pipe, and what we start to get limited by, is we end up with sort of execution
resource bottle necks here. So, next time were gonna start talking
about how to sort of add multiple ALUs, and you can sort of pull this earlier.
And, maybe you can have two multiplies or something like that and try to remove some
of those complexities. But what's nice about this is, if you have
double issue. Out of order right back.
You know this ad instructions that are not dependent on these malls at all, can just
happen. And that's really nice.
Okay we're going to stop here for today.