Re: Reverse engineering of Intel branch predictors

MitchAlsup1 <mitchalsup@aol.com> wrote:

On Mon, 11 Nov 2024 22:10:14 +0000, Stefan Monnier wrote:
 

Hmm... but in order not to have bubbles, your prediction structure still
needs to give you a predicted target address (rather than a predicted
index number), right?

Yes, but you use the predicted index number to find the predicted
target IP.

 
Hmm... but that would require fetching that info from memory.
Can you do that without introducing bubbles?

 
In many/most (dynamic) cases, they have already been fetched and all
that
is needed is muxing the indexed field out of Instruction Buffer.
 

If you're lucky it's in the L1 Icache, but that still takes a couple
cycles to get, doesn't it?

 
My 1-wide machine fetches 4-words per cycle.

A two wide machine only adds a AGU and can do a load and math the same
cycle, so how much bigger is that?

My 6-wide machine fetches 3 ½-cache-lines per cycle.
 
Sure, if the indexed field is not already present, then you have to
go fetch it, but since the table immediately follows JTT, most of the
time, they have already arrived by the time JTT gets to DECODE.
 

Or do you have a dedicated "jump table cache" as part of your jump
prediction tables?  [ Even if you do, it still means your prediction
has to first predict an index and then look it up in the table, which
increases its latency.  I don't know what kind of latency is used in
current state of the art predictors, but IIUC any increase in latency
can be quite costly.  ]

 
For the wider OoO machine, you will have something like a jump table
cache
hashed with some branch history and other data to "whiten" the address
space so one JTT table does not alias with another.

 
 
Stefan