[libre-riscv-dev] uniform instruction format
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon Jun 17 02:50:05 BST 2019
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>
> > 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
> 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
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
More information about the libre-riscv-dev