Semantics for averaging add/sub
I’m somewhat unclear on the intended semantics for the vector fixed-point averaging add/sub instructions. The description is “The averaging add and subtract instructions right shift the result by one bit and round off the result…” Is the intention that the addition or subtraction produce a SEW+1-bit result that is then shifted, or a SEW-bit result?
For example, for SEW = 8, would vaaddu applied to 0xc0 and 0x80 be computed as the result 0x140 shifted to 0xa0, or as the result 0x40 shifted to 0x20?
The description about no overflow suggests the 9-bit result interpretation. But if that’s the case, why separate unsigned and signed versions of the instructions?
Thanks, and cheers,
PA |
|
Section 3.8 provides the following details to clarify the behavior:
Does this help? |
|
Never mind, I’ve worked it out now. I sign- or zero-extend the operand elements depending on whether it’s vaadd or vaaddu, do the addition, then shift and round the result. Gives a sensible answer and exposes the need for signed and unsigned versions of the instructions.
Cheers,
PA
From: tech-vector-ext@... <tech-vector-ext@...>
On Behalf Of Peter Ashenden via lists.riscv.org
Sent: Thursday, 23 March 2023 10:27 To: tech-vector-ext@... Subject: [RISC-V] [tech-vector-ext] Semantics for averaging add/sub
I’m somewhat unclear on the intended semantics for the vector fixed-point averaging add/sub instructions. The description is “The averaging add and subtract instructions right shift the result by one bit and round off the result…” Is the intention that the addition or subtraction produce a SEW+1-bit result that is then shifted, or a SEW-bit result?
For example, for SEW = 8, would vaaddu applied to 0xc0 and 0x80 be computed as the result 0x140 shifted to 0xa0, or as the result 0x40 shifted to 0x20?
The description about no overflow suggests the 9-bit result interpretation. But if that’s the case, why separate unsigned and signed versions of the instructions?
Thanks, and cheers,
PA |
|