Chester (lamchester.delete@this.gmail.com) on August 29, 2022 9:54 pm wrote:
> > > You clearly have no clue the lengths Apple go to to save energy in Fetch.
> >
> > No it's more that you don't understand physical design. Building wider machinery so you
> > can do more work in one cycle so you can "sleep" for a few cycles is not a good thing. The
> > "race to idle" idea you might be basing it on operates on utterly different scales.
> >
>
> Or that reading patents is not the same as showing something is in use in a design. Companies patent
> things all the time just in case they might employ the strategy. That doesn't mean they're using it
> or will use it any time in the future, and doesn't mean anyone else will use it either. Also, patents
> are often extremely vague. That's partially so lawyers have a ton of room to claim patent infringement.
> It also makes them worthless for claiming a certain microarchitecture detail exists.
>
> If you want to claim that "Apple Fetch prediction predicts the trace width, not just the trace address", your
> post needs to include more detail than just patents. Ditto for whether a loop buffer or L0 icache exists.
>
> > BTW In spite of Apple Fetch being so advanced, they actually remains a lot they can still do!
> > While they were early adopters of Decoupled Fetch (as has I think, *everyone* nowadays, eventually),
> > they only have "first stage" decoupling, withe the pipeline looking like
> > [Fetch Address Predict] -> [Fetch cache Access] -> Queue of Instructions -> [Decode].
> > They have not adopted the next step (neither has anyone
> > else yet?), as suggested in Glenn Reinmann's thesis, of
> > [Fetch Address Predict] -> Queue of predicted addresses ->
> > [Fetch cache Access] -> Queue of Instructions -> [Decode].
>
> Pretty sure the second is what everyone does in their high performance designs, except for
> Apple. For the past decade, and more. Apple actually seems to be unique in doing [fetch
> address predict] -> [fetch cache access] -> [fetch result drives next prediction] for their
> main BTB level,

POWER9 seems to do similar. I'm sure the PA6T PowerPC heritage link is purely coincidental. From OpenPOWER user manual: "As instructions are fetched, they are scanned for branches. Up to eight branches are simultaneously processed by the branch prediction logic that predicts both the direction and/or target of the branches, depending on the branch type." It does have some kind of L0 predictor (BTAC) which does predict addresses as well though, unclear how works but it is very fast so not like huge multi level target buffer of x86 CPUs.

It makes sense that Apple really likes a very large I$ if they are doing coupled fetch. And coupled fetch has real benefits, you don't have to predict the presence of a branch, and you don't have to predict target for direct branches (which should be the large majority). This allow equivalent accuracy with smaller structures. Downside being you don't get I$ prefetch prediction from the same structure, and you couldn't avoid taken branch bubbles with high frequency. But that doesn't mean you can't have a prefetch prediction from other structures, as perhaps POWER9 does.