[libre-riscv-dev] [Bug 206] Implement branch prediction

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=206

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #5)
> (In reply to Luke Kenneth Casson Leighton from comment #4)
> > ok i _think_ things are a little different (simpler) here, because the
> > shadow system is easily accessible (a single bit).  if that bit is still
> > active, there's no need for assumptions: you *know* that the branch
> > prediction has not been decided yet.
> 
> Some branch prediction algorithms have a global history buffer where every
> branch is recorded and, in order for the predictor to function properly
> (stay synchronized), there has to be some value entered into the global
> history for each branch that's fetched even if those branches are not known
> to be correct yet.

eurrgh ok, got it.  blegh :)

and that's where the prediction-attacks come into play, hence the article.

> It is actually reversion since the branch predictor is part of the
> instruction fetch pipeline -- before the 6600 OoO engine has a chance to
> affect it. The branch predictor (assuming we don't use a really simplistic
> one) updates its state every cycle -- even before it knows the fetched
> instruction words. When there is a mispredicted branch, we need to reset the
> branch predictor to the state it had when that branch was fetched so we can
> execute the proper sequence of branch predictor steps.

now i'm lost.  and need to understand.

the Branch Function Unit is very simple: it keeps a record of the "alternative"
path Program Counter.  if the branch "fails" then all that happens is that
the shadow "cancel" is called (which destroys all the operations that either
haven't yet completed or were in "waiting to write" mode), the PC will be set
to that "alternative" address, and instruction issue continues from that point.

this gives the *appearance* of reversion, rather than "undoing damaged
register files and memory locations by way of quotes reverting quotes
*actual* register writes etc." because those writes were *never permitted
to take place in the first place*.

trying to "keep track" of that, in a separate ring-buffer (for example),
where the completion (or otherwise) allows for "reversion" by way of
dropping the top items on the buffer...

mmm... i can't say i'm keen on that idea.

we need help, here.


> > it's reasonable and normal to assume that the icache is read-only, we're
> > not going to support self-modifying code.  it's too much :)
> 
> As long as we do support dynamically loading new code by executing the
> icache sync instruction -- the Vulkan driver (as well as Linux itself)
> critically depends on that to be able to execute JIT compiled code.

good catch.  a quick search online shows what isync is / used for:
https://www.ibm.com/developerworks/systems/articles/powerpc.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.