[Libre-soc-dev] mv.zip and mv.unzip (vector pack and unpack)

[lkcl]

love the override meaning of Saturation signed/unsigned to give more constants.  put it in the page.

can't do 0 -max +max in the same instruction, annoyingly, unless using zeroing predication hmm i am getting brainmeltdown thinking of how that would work, urr there is both sz and dz.

nornal mode: https://libre-soc.org/openpower/sv/normal/

10	N	dz sz	sat mode: N=0/1 u/s

if dz is set then zeros would be inserted on swizzle-skipped elements, but the sat/u would remain... no, too complicated.

two mv instructions it'll have to be, one for zeros, the other for sat/u.

skipping is COMPLEX it basically means a static predicate mask built-in to the swizzle, but the implication is that the source subvec len is *different* from the dest, despite the number of elements actually copied being the same.

hence why i am getting irritated (with myself) having to think through the combinations.

l.




On June 13, 2022 5:36:56 PM GMT+01:00, Jacob Lifshay <programmerjake at gmail.com> wrote:
>On Mon, Jun 13, 2022, 08:17 lkcl via Libre-soc-dev <
>libre-soc-dev at lists.libre-soc.org> wrote:
>
>> https://libre-soc.org/openpower/sv/mv.swizzle/
>> https://libre-soc.org/openpower/sv/mv.vec
>>
>> these two are driving me slightly nuts.  there are a hell of a lot of
>> combinations to think through, and iteratively i have gone through a
>hell
>> of a lot of things that just won't work.
>>
>
>one thing that occurred to me: we need fmv.swizzle and maybe
>mvfixed[u].swizzle too (integers where 0.0 maps to 0 and 1.0 maps to
>the
>max signed/unsigned integer -- used for fixed-point swizzle such as
>pixel
>data -- we need signed ints for efficient bump map support for some
>programs). the 0.0 and 1.0 constants should map to 0, 1 for mv.swizzle,
>0.0, 1.0 for fmv.swizzle, 0, UINT_MAX for mvfixedu.swizzle, and 0,
>INT_MAX
>for mvfixed.swizzle.
>
>i like the idea of a SKIP option!
>
>Jacob