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.
