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.