similar to vpack vunpack except generalised, these eventually got added
via a "Management" instruction - using svstep - to set the pack/unpack
reordering in SVSTATE.
end result is an automatic "transpose" of the walking-order of vec2/3/4
as a 2D array, one transpose on source registers and one transpose on
destination: both are *independent*.
subvl now confirmed functional including with predicate masks
beginning the process, converting LDST-with-immediate instructions
lwz, stz etc. from EXTRA3 to EXTRA2-with-pack/unpack room
this has meant some unit tests changed, they can no longer use
regs 0 1 2 3 4 ... they have to be 0 2 4 6 8 ...
you're not going to believe this, but pack/unpack as a mode
doesn't work. it has to be in SVSTATE (like the vertical-first
and this is because of vertical-first.
setting the swapping of the two outer-inner loops
makes absolutely no sense in vertical-first mode
if pack/unpack is set as a *mode* on individual
it is fine on horizontal-first but not vertical-first.
that in turn means it has to go into setvl, and there's not
enough bits left. which means it has to go into sv.setvl.
which means defining a new RM Mode page.
commit 04d0ba9a29869a06becd424de6184fc95dfc643d (HEAD -> master)
Author: Luke Kenneth Casson Leighton <email@example.com>
Date: Mon Sep 12 22:36:29 2022 +0100
add hack overloaded meaning of destwid to be pack/unpack.
only supposed to be used on sv.setvl
(In reply to Luke Kenneth Casson Leighton from comment #5)
> that in turn means it has to go into setvl, and there's not
> enough bits left. which means it has to go into sv.setvl.
> which means defining a new RM Mode page.
the epic saga continues.
sv.setvl is not practical. it is a 64-bit encoding embedded into
a Vector Loop encoding and that is prohibited. we need an *EXT001*
encoding **not** an sv.xxx encoding.
in the meantime (sigh) i will add an "svmgmt" instruction which
temporarily focusses on a pack/unpack argument.
potentially it could be a 10-bit XO because there are fewer bits in
i have a much simpler idea, as this is 2 bits, to borrow from svstep "SVi" argument. yes we do need to rename that field.
What's needed here from binutils or pysvp64asm or pysvp64dis?
(In reply to Dmitry Selyutin from comment #9)
> What's needed here from binutils or pysvp64asm or pysvp64dis?
hilariously, nothing - it has all moved (after many attempts)
to setting 2 bits of SVSTATE from svstep (see comment #8)
Ehm, so what's the fate of this budget-wise? :-)
(In reply to Dmitry Selyutin from comment #11)
> Ehm, so what's the fate of this budget-wise? :-)
well there's been a hell of a lot done underneath...
finally got it working. predication unit test is next, just to
sorted out - finally.
last unit test also added,