The non-normative text you quoted should be edited to delete the words “it is signed”.

The immediate is sign-extended, but then is treated as an unsigned value. So the operation doesn’t differ based on the argument type.

(This sign-extended-but-unsigned-immediate pattern is also exists for e.g. sltiu in the base ISA and vmsgtu.vi in the vector extension.)

On Wed, Sep 2, 2020 at 1:58 PM CDS <cohen.steed@...> wrote:

From chapter 11, section 1 (#3):

The 5-bit immediate is unsigned when either providing a register index in vrgather or a count for shift, clip, or slide. In all other cases

it is signed and sign extended to SEW bits, even for bitwise and unsigned instructions, notably compare and add.

From chapter 13, section 1:
Saturating forms of integer add and subtract are provided, for both signed and unsigned integers. If the result would overflow the destination, the result is replaced with the closest representable value, and the vxsat bit is set.

This results in a conundrum:
operation  SEW   RS1   RS2
vsaddu.vv  8  0x0ff   0x01
vsaddu.vi  8  0x01f   0x01

These two operations now provide a difference of result.
Taking the maximum unsigned integer value, adding one, causes saturation. The result value for the vector-vector operation would be 0xff and the VXSAT bit would be set. This shouldn't be a surprise.
However, the immediate form is more difficult. The immediate value is sign-extended to SEW size and treated as a signed value. This means the arithmetic is now (-1) + 1 = 0. This does not create a saturation (a value outside expected return parameters). The result value from the vector-immediate operation would be 0x1f and the VXSAT bit would be clear.

This is from the specification, as written, in a strict sense.

From a use-case sense, what is trying to be accomplished, here? Two counter perspectives:
1 - from a use-case perspective, why would a programmer or compiler specifically pick an unsigned operation, only to operate on values using a signed-immediate in a signed format? I'm curious that this case is.
2 - from an architecture/implementation perspective, this is the first time that an engine will have to operate on an instruction differently based on the *source* of the operand. That is, more narrowly, the arithmetic engines are given an operation encoding (usually an "onto" mapping from the opcode space) and operands, but does not care where the operations came from. In other words, the vector engine itself would receive a full bit set in RS1 for both cases, above, for a saturating unsigned (sorta) add. However, the outcome is required to be different?

I would imagine others have run into this situation, and I'd like to know both the intent of having a signed-immediate value for this unsigned operation, as well as the applicability of section 11.1 to this instruction.