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

[lkcl]

On Sun, Jun 5, 2022 at 11:20 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
> On Sun, Jun 5, 2022, 02:58 lkcl <luke.leighton at gmail.com> wrote:
>> 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:

i've already begun listing the exceptions (quirks) here. they're... considerable
https://libre-soc.org/openpower/sv/svp64_quirks/

in it i've already done the thought-experiment of what happens if
instructions are proposed as SVP64-only: it doesn't go well. it will
be required to request the 32-bit Scalar ISA Reservation purely
to prevent and prohibit a conflict.  should that not become granted
by the ISA WG it quickly becomes absolute hell.

even just having to spend the time explaining why the reservation
has to exist risks pissing off the ISA WG who will have limited time
and goodwill.

the answer's no.

> 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.

it turns out that with a little thought, in each case, things can be made
to work or there is an alternative.  or that they're so insanely expensive
that as vector instructions they cannot in any way be justified.  conflictd
is a good example.

> (though it just occurred to me it could be justified as an s-box operation for cryptography).

that works just as well if not better as Indexed-REMAP.

> then propose it as part of SV or an extension that depends on SV.

no.  not doing it. been through the thought-experiment of how that
would go with the ISA WG, i can't sell it.

> being completely general has downsides...a big one is efficiency.

in most circumstances i would agree.  however in this particular
case where micro-coding is almost certainly going to have to be
deployed, that micro-coding hardware simply moves sideways
and is attached to the Indexed-REMAP engine instead.

> I think we should limit the completely general parts to the instructions
> where they're actually *the operation* those instructions are designed to do

this is literally the antithesis of the SV paradigm, jacob!

> -- 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.

that's an implementation detail.  you've done this a number of times, now:
conflated implementation details with ISA design.

this way of thinking has been precisely why the entire software industry is in
such absolute hell, because the inner workings of the SIMD ALUs is directly
exposed to the programmer and they're expected to like it.

such a choice of micro-architecture is up to the *architect*.

> we could define mv.x to be a SV-only instruction...it would illegal instruction trap if not sv prefixed.

no.  that's even worse, sorry.

the "good-will" and available time of the ISA WG has to be considered
as a "limited resource".  if we piss them off with poorly-thought-out
design they're going to start arbitrarily rejecting proposals not on
their technical merits good or bad but on the unworkability of
considering them *at all*.

there have already been complaints and alarms raised inside the
OPF Membership at the size of SV.  *i* have been raising alarms
as well, ironically, for over 18 months.

anything that risks pissing off the ISA WG Members *has* to take
a back seat.

mv.x is out.

l.