Add a "nextPc" interface so that lookup can begin in the previous cycle.
Remove the "pc" operands in the vector of lookup interfaces,
but rather derive the PC from lookup from the first PC being looked up
in that cycle. That is, by adding 4*(interface number) to the beginning
lookup PC. As this might not actually be the PC of the instruction,
pass the index you used with the training info so that you are certain
to train with the same index you looked up.
This has less than 1% overhead in CoreMark.
This is a general improvement for reasonable timing which should be upstreamed.
the vector of instructions outside of the decode loop to improve timing.
Specifically, the branch direction prediction is lifted out and depends
only on whether there is agreement between direction prediction and a
branch being predicted by fetch, not on the actual predicted next PC.
This appears to keep the global history clean enough to
perform on-par with the old design in CoreMark.
This is a general timing improvement and should be upstreamed.
This should not be a primary degredation of performance since the
redirection gets on seperately from this update which will only affect
future predictions.
improvements that can be upstreamed.
Basically, only use addresses in these predictors rather than
capabilities, and just pass an address in from the FetchStage.
Sc is unique in that it writes both memory and a register value.
This implementation works around the fact that the memory store data and
the register write data are sharing the same field in the reorder buffer
by inferring the writeback value of Sc from the byteEnable field.
All of St, Amo, Lr and Sc use the normal 3-bit encoding for the width;
rather than add Lr and Sc to the list, switch it just to exclude Ld as
the special case that's handled by the other half of the expression.
Previously LR.C and SC.C were decoded as LR.BU and SC.BU.
nextPc only reflected things known in the Decode stage, but not before
(i.e. BTB predictions).
This meant that we were pretty much always redirecting JRs.
I needed to pipe through whether a jump was predicted by the BTB or not,
and then only stop predicting if there is no nextPc prediction and also
no BTB prediction. This should actually reasonably approximate SBC.
Also, this one is not "redirecting", it's just flushing (flipping
decode_epoch_local), trusting that we'll get a later redirection.
We think that we were wedging on IFetch bus error.
It appears that we didn't make the last instruction fragment valid in the bus error case, and expect that this path was not previously exercised.
This change returns 0s (to hopefully make the error less subtle) in exactly the right number of fragments.
