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*.
https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=c42523e2cb7b0f95fe7a2da58689ebea3a4a2f85 subvl now confirmed functional including with predicate masks
https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=91d0f643c324f7fa2ea5a427f842067655b261e4 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 ...
feedback request https://lists.libre-soc.org/pipermail/libre-soc-dev/2022-July/005132.html
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 bit). 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 instructions. it is fine on horizontal-first but not vertical-first. dang.
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. haaaaaaa...
commit 04d0ba9a29869a06becd424de6184fc95dfc643d (HEAD -> master) Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> 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. > > haaaaaaa... 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 SVSTATE left.
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...
https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=12a7e7b6d7b589d5227fa4863d8e7aeac81ec936 https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=31043ea9d551b98f22d0b0184bd64c1e6b01c44d finally got it working. predication unit test is next, just to make sure
sorted out - finally. https://lists.libre-soc.org/pipermail/libre-soc-dev/2022-September/005271.html https://lists.libre-soc.org/pipermail/libre-soc-dev/2022-September/005323.html last unit test also added, https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=20809f740abcb1a412decd26b94691c83ce2222e