[libre-riscv-dev] uniform instruction format

[Luke Kenneth Casson Leighton]

On Sun, Jun 16, 2019 at 10:03 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Sun, Jun 16, 2019, 11:17 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > thus, the gather/scatter "lsk" can be removed, as it is covered by
> > twin-predication, and an extra instruction to provide gather/scatter
> > is NOT required.
> >
> as covered in
> http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-February/000599.html
> even if we have twin predication (which I'm not against adding),
> gather/scatter is strictly more powerful and is especially necessary for
> memory operations.

 no, that's completely different: it's not called gather/scatter:
that's MV.X, which we discussed already is likely needed as a separate
operation, which i had already noted about 15 months ago in the
original SV was a necessary additional opcode.

we also discussed if i recall that it was best to do MV.X as an
"offset" version (starting relative to another register rather than
being an absolute register index) as a relative version can have the
execution engine reserve a range of registers (within N to N+VL-1)
whereas with the static version, *all* registers have to be reserved,
and the entire execution stall.


my understanding of the conventions from the design of Vector
Instruction Sets gather/scatter is a linear gather and a linear
scatter: the sequence to be gathered is expressed in a
sequentially-increasing set of indices: the sequence to be scattered
is expressed in a sequentially-increasing set of indices.

MV.X, which really requires a completely new opcode, permits an
arbitrary unordered set of indices.

damnit it's been such a long time i can't even recall properly the
months and months of work i did on the original SV.  i *think* i found
a way to mark one of the registers. i'll have to look again.


ah.  ok.  right, i think i understand.  LLVM i believe uses the
concept "gather/scatter" incorrectly, assigning it *arbitrary*
(unordered) meaning.   through the mistaken naming (by calling it
gather/scatter instead of MV.X), confusion has arisen.

right.  found the notes.  it's called VSELECT.  VSELECT is the only
one of the Vectorisation concepts that's not possible to do with
twin-predication.


also it is not necessary to restrict the power of the hardware, adding
non-orthogonality, just because a novel concept happens not to be
commonly used or known.

twin predication covers every single commonly-used vector operation
and adds at least one un-common (new) type of operation.  that (new)
capability doesn't *have* to be added to compilers, right this very
minute.

l.