[Libre-soc-dev] [RFC] SVP64 on branch instructions

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, Aug 2, 2021 at 8:42 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Sun, Aug 1, 2021, 17:41 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > https://libre-soc.org/openpower/sv/branches/
> >
> > i created this page with various modes, i believe only "ALL/SOME" is
> > needed because by inverting the BO test itself ~ALL and ~SOME are
> > achieved.
> >
>
> Instead of "SOME", I'd call the mode "ANY" -- it's more specific.
> Alternatively we could call the modes reduce-and/reduce-or, since that's
> what they actually are.

the bit is named "ALL" to indicate "All tests must pass".

> GPU code could benefit from having the semantics be where the SVP64
> predicate (either Int or CR) tells the branch instruction which CR fields
> it should use,

yes, that's a given.

> where zero bits in the SVP64 predicate cause the
> corresponding CR fields to be ignored.

that's part of SVP64 default behaviour: those tests would simply
be skipped.

i have however just realised that zeroing mode is completely meaningless,
including the SNZ bit... ah no it isn't, because it can be set to deliberately
fail at the first zero point.

that can be used to very deliberately truncate VL to the exact point where
the first zero point occurs in the predicate mask.... argh can't do that,
we've run out of bits.  nuts.  oh wait... VLI is to truncate to VL rather than
VL-1.  so it's not so bad.

> Since the ignored bits cause ~ALL
> and ~ANY to no longer be redundant afaict,

can you re-read, about sz and SNZ, to take those into consideration?

> The above would take additional instructions if the semantics of br were
> instead defined as currently in the wiki, instead of my proposal.

i'm not totally following, i'm still absorbing the concept of what you're
describing, however a couple of things:

1) changing the behaviour and semantics of SVP64 predicate masks
just for SVP64 isn't ok.  fitting with how SVP64 predicate masks work
for all other options is how it has to go at this point

2) you may not have understood about sv and SNZ, or, if i am reading
correctly what you wrote, you may have misunderstood predicate
masks and how they're applied (or, not).

can you please re-evaluate / re-word, taking into account sz and SNZ,
which can be used to insert (effectively) *either* an immediate of zeros
or an immediate of 1s in place of masked-out CR bits being tested?

l.