On 7/17/21 3:13 PM, Peter Maydell wrote:
On Sat, 17 Jul 2021 at 21:50, Richard Henderson
<richard.hender...@linaro.org> wrote:
On 7/13/21 6:37 AM, Peter Maydell wrote:
+#define DO_VABAV(OP, ESIZE, TYPE) \
+ uint32_t HELPER(glue(mve_, OP))(CPUARMState *env, void *vn, \
+ void *vm, uint32_t ra) \
+ { \
+ uint16_t mask = mve_element_mask(env); \
+ unsigned e; \
+ TYPE *m = vm, *n = vn; \
+ for (e = 0; e < 16 / ESIZE; e++, mask >>= ESIZE) { \
+ if (mask & 1) { \
+ int64_t n0 = n[H##ESIZE(e)]; \
+ int64_t m0 = m[H##ESIZE(e)]; \
+ uint32_t r = n0 >= m0 ? (n0 - m0) : (m0 - n0); \
Any particular reason you're not using TYPE for n0 and m0?
I wanted to definitely be doing the subtraction with a signed
type wider than the inputs, because that's the way the
pseudocode effectively deals with it, and I didn't feel like
thinking through whether using the smaller and possibly
unsigned types would DTRT :-)
Fair enough. Now that I think of it, I would expect the compiler to narrow the operation
based on the result type. So, unconditional r-b.
r~
