[libre-riscv-dev] uniform instruction format

[Jacob Lifshay]

On Sun, Jun 16, 2019 at 6:50 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> 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.
having vectorized random-access loads/stores is called gather/scatter
(or sometimes indexed load/store). what you were thinking of
(load/store from successive addresses of the form a*n+b) is called a
strided load/store. MV.X is a register gather: it's like a memory
gather, but a memory gather is strictly more powerful in that MV.X can
be emulated by a memory gather but not vice-versa. MV.X is just an
optimization on doing a vector store then a memory gather.

See also:
intel's AVX512 gather/scatter instructions:
https://www.felixcloutier.com/x86/vgatherqps:vgatherqpd
https://www.felixcloutier.com/x86/vpscatterdd:vpscatterdq:vpscatterqd:vpscatterqq
>
> 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.
from what I understand (and any decent GPU requires) is that
gather/scatter operations do not require the vector of addresses to
have any patterns (other than maybe requiring the addresses to be
aligned to a multiple of the element size).
>
> 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.
actually, LLVM uses gather/scatter correctly. if llvm had been
incorrect, why does x86's instruction set naming agree?
>
> 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.
it's one that can't be done using twin-predication, but it's not the only one.
>
>
> 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.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev