Add Zvzip extension

[Ved Shanbhogue (ved-rivos)]

Zvzip standard extension provides instructions for reordering structured data in vector registers. These instruction address usages such as packing and unpacking data structures such as color components of a pixel, real and imaginary components of complex numbers, transposing small matrices, among others.

[Andrew Waterman (aswaterman)]

Thanks! As usual, we'll leave this open until ratification.

[Nadime Barhoumi (nadime15)]

Is it intentional that this chapter is not included in the compilation flow? Since it’s not embedded anywhere (e.g., in /src/riscv-unprivileged.adoc), it won’t appear in the final artifacts.

[Ved Shanbhogue (ved-rivos)]

Is it intentional that this chapter is not included in the compilation flow? Since it’s not embedded anywhere (e.g., in /src/riscv-unprivileged.adoc), it won’t appear in the final artifacts.

I have included it in the build but it may not be the best place to include the chapter.

[Nicolas Brunie (nibrunie)]

Although it seems all those instructions support optional masking, there are very few information about the masking behavior (in particular which index of mask should be used for each result element in vzip.vv). I am wondering if it could be integrated in the pseudo code or described somewhat.

[Ved Shanbhogue (ved-rivos)]

Although it seems all those instructions support optional masking, there are very few information about the masking behavior (in particular which index of mask should be used for each result element in vzip.vv). I am wondering if it could be integrated in the pseudo code or described somewhat.

Nicolas Brunie (@nibrunie) The pseudocode is updated to include the masking behavior. Please take a look.

[Nicolas Brunie (nibrunieAtSi5)]

Although it seems all those instructions support optional masking, there are very few information about the masking behavior (in particular which index of mask should be used for each result element in vzip.vv). I am wondering if it could be integrated in the pseudo code or described somewhat.

Nicolas Brunie (@nibrunie) The pseudocode is updated to include the masking behavior. Please take a look.

Looks good to me, thank you for making the changes Ved Shanbhogue (@ved-rivos).

[Nadime Barhoumi (nadime15)]

Ved Shanbhogue (@ved-rivos) I guess the extension depends on Zve32x, right? If so, I think this should be mentioned.

[Ved Shanbhogue (ved-rivos)]

I guess the extension depends on Zve32x, right? If so, I think this should be mentioned.

The extension depends on the V Extension for Application Processors or the Zve32x Extension for Embedded Processors. I will mention it.

[Nadime Barhoumi (nadime15)]

Zve32x is a subset of V, so mentioning Zve32x should be enough.

[Nicolas Brunie (nibrunieAtSi5)]

Zve32x is a subset of V, so mentioning Zve32x should be enough.

Agreed with Nadime Barhoumi (@nadime15) , V implies Zve32x, so mentioning Zve32x should be enough (Zve64x could be added to extend to SEW=64 case).
No mention of v should be required IMHO (we have done that in the past for other extensions and I think it was a mistake).

[Olaf Bernstein (camel-cdr)]

Would it be appropriate to add notes to each instruction for how they can be implemented by software in base RVV?

Because I suspect people will search the spec for things like "zip" or "transpose", when needing those things in code, and there are relatively efficient patterns for all of them (much better than vrgather), which are non-trivial to come up with:

vzip.vv vd, vs1, vs2 -> vwaddu.vv vd, vs1, vs2; vwmaccu.vx vd, -1, vs2

vunzipe.v vd, vs1 -> vnsrl.vx vd, vs1, 0
vunzipo.v vd, vs1 -> vnsrl.vx vd, vs1, \SEW/8

vpaire.v vd, vs1, vd -> vslide1up.vx   vd, vs1, 0, vm=odd-bits
vpairo.v vd, vs1, vd -> vslide1down.vx vd, vs1, 0, vm=even-bits

[Nicolas Brunie (nibrunieAtSi5)]

Would it be appropriate to add notes to each instruction for how they can be implemented by software in base RVV?

Because I suspect people will search the spec for things like "zip" or "transpose", when needing those things in code, and there are relatively efficient patterns for all of them (much better than vrgather), which are non-trivial to come up with:

vzip.vv vd, vs1, vs2 -> vwaddu.vv vd, vs1, vs2; vwmaccu.vx vd, -1, vs2

vunzipe.v vd, vs1 -> vnsrl.vx vd, vs1, 0
vunzipo.v vd, vs1 -> vnsrl.vx vd, vs1, \SEW/8

vpaire.v vd, vs1, vd -> vslide1up.vx   vd, vs1, 0, vm=odd-bits
vpairo.v vd, vs1, vd -> vslide1down.vx vd, vs1, 0, vm=even-bits

Does the first pattern work for any SEW (including ELEN) ?

[Olaf Bernstein (camel-cdr)]

The unzip/zip pattern doesn't work for SEW=ELEN

[Xu Shicheng (Xu-Dsus4)]

Hi all, I would like to clarify whether there should be a constraint of "if masked, cannot overlap the mask register" for all instructions in the zvzip extension. Currently, the specification only mentions that this check needs to be performed for vpairo/vpaire. Thanks.

[Andrew Waterman (aswaterman)]

Xu Shicheng (@Xu-Dsus4) All vector instructions have a standard set of overlap rules, unless otherwise relaxed. Those rules include the one you mention. The spec authors can comment, but my guess is that the vpairo/vpaire mask-overlap rules are redundant.