[Libre-soc-dev] sv.mv x: the instruction from hell

[Jacob Lifshay]

On Sun, Jun 5, 2022, 02:58 lkcl <luke.leighton at gmail.com> wrote:

> On Sun, Jun 5, 2022 at 8:39 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > sorry, having mv.x be 2-operand like that is totally unworkable --
> sv.mv.x is supposed to be dynamic swizzle where the indexes read from one
> vector are used as the indexes of which elements to copy from a second
> vector to the destination. It inherently needs 3 operands.
>
> the rule is: the scalar instruction has to exist, first, and it has to
> exist
> on its own merit.
>

well, sorry, that rule needs to have exceptions: there are some very
necessary/important vector operations that don't really have a scalar
version with much merit: mv.x is one of those. (though it just occurred to
me it could be justified as an s-box operation for cryptography).

>
> what *scalar* instruction can be proposed - stand-alone - which does
> *not* rely *in any way shape or form* on SV - that is not so absolutely
> awful that the ISA WG rejects it for very valid reasons.
>

then propose it as part of SV or an extension that depends on SV. don't try
and make it independent of SV. that would be like trying to get fsin added
but without making it require the existance of the fp registers it uses for
input/output -- just plain silly (though modifying all fp ops to use
integer registers could be useful -- risc-v has Zfinx and Zdinx for fp in
integer regs).

>
> you're laser-focussing on SV only to the detriment of the rest of the ISA,
> and we have to be in a position to have good justification for *everything*
> that is proposed.  mv.x as a stand-alone Scalar instruction is so bad that
> i would *agree* with any objections by the ISA WG to its inclusion, and
> consequently it cannot be relied on to exist as a basis for an SVP64
> variant.
>
> when added as a REMAP we can get away with calling it "advanced SVP64"
> and there will be not only far less objection (because it's part of
> something
> that's entirely new that has no effect on the Scalar ISA), it has far more
> uses and makes the entire ISA that much more powerful.
>

being completely general has downsides...a big one is efficiency. I think
we should limit the completely general parts to the instructions where
they're actually *the operation* those instructions are designed to do --
mv.x. everything else greatly benefits from not being completely general
which allows it to easily pack the elements into simd alus (the decoder can
do things like issue 8x8-bit microops) without having to do something like
independently route each byte from/to the register file since every byte
could come from any byte in any register.

Jacob