[libre-riscv-dev] outstanding commit pending counters (for multi issue)

[Luke Kenneth Casson Leighton]

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
predication* map.

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.

l.