Heikki Kultala (heikk.i.kultala.a.delete@this.gmail.com) on July 23, 2020 2:53 am wrote:
> Ray (no.delete@this.thanks.com) on July 22, 2020 12:49 pm wrote:
> > Heikki Kultala (heikk.i.kultala.a.delete@this.gmail.com) on July 22, 2020 12:31 pm wrote:
> > [snip]
> > > I was not talking about ITANIUM having something good in it, but EPIC (ie marking some instructions
> > > as independent of each others, without scheduling them) having some good in it.
> > >
> > [snip]
> > > I know that OoOE is vital.
> > >
> > > I was thinking about that could EPIC(as in general idea of marking some instructions as indepedent
> > > of each other, not itanium ISA) in any way help to make a better OoOE processor.
> > [snip]
> >
> > You just gave me a idea. I'm no CPU designer, so it might be a dumb idea, but here goes...
> >
> > How about turning that concept on its head? The compiler marks instructions that are hopelessly
> > in-order and interdependent on each other. The CPU would route such instructions to a low
> > power in-order backend. Basically, give up on the idea of trying to speed up those instructions,
> > but maybe get back the trade-off that you could execute them in a very low power way instead.
> > I guess it could be used as some kind of serialization guarantee too?
> >
> > Is there any context in current-day computing where this could make sense?
>
> I have been thinking something related to this also, I even wrote a very simple instruction set
> simulator for this kind of architecture few years ago in couple of days to test things out.
>
> But my idea was that we do not have separate in-order backend for these but
> instead that we can have pipes which can execute these 1-4 instruction serial
> bundles, but then we freely do out-of-order execution BETWEEN the bundles.
>
> This would mean that the OoOE logic would have less instructions to track(as it tracks bundles of maybe
> average of 2 instructions), but everything would still be dynamically scheduled on the high-level.
>
> Many register writes could also be eliminated and instruction encoding could
> be denser as the next instruction in the bundle always uses the value the previous
> instruction created (software bypassing with dead result elimination)
>
> I have not abandoned this idea either. I just haven't had the time to play more with it.

If you look at the Power4 and other similar designs, where bundles of uops are tracked together, many CPUs do this implicitly.

David