Zvabd Draft Spec

[keyon1992]

It is the draft spec of Zvabd extension for integer vector absolute difference instructions.

[nibrunieAtSi5]

Does this indicate that the instruction is always masked or am I misreading the SAIL code ?

[keyon1992]

It follows the RVV sail code but omit the initialization code for mask/sew/lmul since these instructions are designed as standard vector arithmetic instruction and the full sail code is too long. If this has caused a misunderstanding, we need to find a way to resolve it.

[nibrunieAtSi5]

I would define this with the reciprocal: "SEW is not 8 nor 16" (we never know which new SEW values may appear in the future)

[bgrayson-mips]

Minor nit: I would rephrase it as "neither 8 nor 16".

[nibrunieAtSi5]

One question: why is there no vector-scalar / .vx variants of the instructions ?

It seems the opcode are free, or at least riscv-opcodes does not complain when:

diff --git a/extensions/unratified/rv_zvabd b/extensions/unratified/rv_zvabd
index 9bf8b48..6d348b0 100644
--- a/extensions/unratified/rv_zvabd
+++ b/extensions/unratified/rv_zvabd
@@ -4,3 +4,8 @@ vabd.vv       31..26=0x11 vm vs2 vs1 14..12=0x2 vd 6..0=0x57
 vabdu.vv      31..26=0x13 vm vs2 vs1 14..12=0x2 vd 6..0=0x57
 vwabda.vv     31..26=0x15 vm vs2 vs1 14..12=0x2 vd 6..0=0x57
 vwabdau.vv    31..26=0x16 vm vs2 vs1 14..12=0x2 vd 6..0=0x57
+
+vabd.vx       31..26=0x11 vm vs2 rs1 14..12=0x6 vd 6..0=0x57
+vabdu.vx      31..26=0x13 vm vs2 rs1 14..12=0x6 vd 6..0=0x57
+vwabda.vx     31..26=0x15 vm vs2 rs1 14..12=0x6 vd 6..0=0x57
+vwabdau.vx    31..26=0x16 vm vs2 rs1 14..12=0x6 vd 6..0=0x57

Note that this would allow to define vabs.v as a pseudo instruction vabd.x vd, vs2, x0 (which would require to allow vabd for SEW=8, 16, ..., ELEN to get the same support as vabs.v.

Andrew made an interesting suggestion: in all cases vabs.v should be encoded by vabd.vx vd, vs2, x0 even if that is the only supported (non-reserved) variant of vabd.vx (it would also be the only variant supported on the extended SEW range).

[keyon1992]

One question: why is there no vector-scalar / .vx variants of the instructions ?

It seems the opcode are free, or at least riscv-opcodes does not complain when:

diff --git a/extensions/unratified/rv_zvabd b/extensions/unratified/rv_zvabd
index 9bf8b48..6d348b0 100644
--- a/extensions/unratified/rv_zvabd
+++ b/extensions/unratified/rv_zvabd
@@ -4,3 +4,8 @@ vabd.vv       31..26=0x11 vm vs2 vs1 14..12=0x2 vd 6..0=0x57
 vabdu.vv      31..26=0x13 vm vs2 vs1 14..12=0x2 vd 6..0=0x57
 vwabda.vv     31..26=0x15 vm vs2 vs1 14..12=0x2 vd 6..0=0x57
 vwabdau.vv    31..26=0x16 vm vs2 vs1 14..12=0x2 vd 6..0=0x57
+
+vabd.vx       31..26=0x11 vm vs2 rs1 14..12=0x6 vd 6..0=0x57
+vabdu.vx      31..26=0x13 vm vs2 rs1 14..12=0x6 vd 6..0=0x57
+vwabda.vx     31..26=0x15 vm vs2 rs1 14..12=0x6 vd 6..0=0x57
+vwabdau.vx    31..26=0x16 vm vs2 rs1 14..12=0x6 vd 6..0=0x57

Note that this would allow to define vabs.v as a pseudo instruction vabd.x vd, vs2, x0 (which would require to allow vabd for SEW=8, 16, ..., ELEN to get the same support as vabs.v.

Andrew made an interesting suggestion: in all cases vabs.v should be encoded by vabd.vx vd, vs2, x0 even if that is the only supported (non-reserved) variant of vabd.vx (it would also be the only variant supported on the extended SEW range).

I fully agree with you, and the original proposal was also designed this way, but the feedback from ARC is completely the opposite. We must prove that .vx is widely used and has value, otherwise the encoding should be reserved. If .vx has only one usage, x0, then defining a vabs.v and placing it in the VXUNARY0 domain is a more encoding-space-efficient approach.
By the way, the limited SEW support also comes from the ARC comments:

• The proposers are requested to consider whether this extension should not support all element sizes from 8-bits to 64-bits. It appears that the justifying use cases are based on 8-bit integers. And maybe there are other major use cases that might justify 16-bit integer support?
• In short, since this extension targets a specific yet important class of applications (video codecs like x264), implementations of this extension should not be burdened with supporting data types that are not of notable value to these or similar applications.