[libre-riscv-dev] outstanding commit pending counters (for multi issue)
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Jun 7 22:58:40 BST 2019
On Fri, Jun 7, 2019 at 5:15 PM Mitchalsup <mitchalsup at aol.com> wrote:
> Observation #1: No register write order* is needed if there have been no raised exceptions.
> (*) except for the std WAW stuff.
i'm overloading / co-opting the shadow system to do WaW: it works well.
> So, you might want some logic to accumulate raised excpt, and if this branch shadow has
> no raised exceptions, the writes can happen OoO.
> Other than that It looks like you are on an acceptable track forward.
really appreciated the review.
the reason i am being slightly paranoid about a full commit-order is
because of the overloading of multi-issue to provide vectorisation.
in a vectorisation context, the program counter effectively does a
kind-of "floating point side-step":
PC=0x1234 ADD r1
PC=0x1238 MUL r2
PC=0x123c.0 MUL r3 (vector el=0 - note that PC does not change)
PC=0x123c.1 MUL r4 (vector el=1 - note that PC does not change)
PC=0x123c.2 MUL r5 (vector el=2 - note that PC does not change)
PC=0x1240 ADD r31 (not vectors any more)
which is fine as out-of-order commit, for everything except
low-latency interrupts and exceptions. if there's no exceptions, the
vectored elements may be viewed as atomically-completable.
LD/STs, if an exception occurs in the middle of a run, and there were
some elements that committed out-of-order and some that did not, it's
required to have a full vector-bitmap of the elements that completed
and of those that raised exceptions, and when it comes to re-issuing
them (restarting after the trap) use the bitmap as an *additional
if however there are guaranteed in-order commit semantics the only
information needed to be stored is that "floating point mantissa"
kinda-thing attached to the PC. no additional predication would be
required, because by restarting after the trap at where the counter
(an extension of the PC) left off...
that's a *lot* easier!
there is another reason: formal mathematical proofs. my feeling is
that a formal proof of a system that had out-of-order execution but
guaranteed commit order would be a lot easier to do a proof for than
one that permitted out-of-order commit.
More information about the libre-riscv-dev