Hi Bruce, Do you mean vrgather instead of vslide? I use vrgather_vx_* and vslidedown to perform a vector element rotate (and other things), see:

| could an extension just change state like the number of vector registers? | Don't understand tbis question - please elaborate. Krste

Thanks, I must have missed this bit: "4.5. Mapping with LMUL > 1 and ELEN > VLEN If vector registers are grouped to support larger SEW, with ELEN > VLEN, the vector registers in the group are

Section 4.5, Krste | On Wed, Jun 2, 2021 at 8:38 AM Andrew Waterman <andrew@...> wrote: | It’s actually not fundamental to the ISA design that VLEN >= ELEN. An | implementation with

could an extension just change state like the number of vector registers?

We do allow supported SEW to vary with LMUL, so implementation can support single-width operations on SEW=64. See section 4.5, Krste | So, (on a 32x 32-bit vector register machine) the widening and

The VLEN>=128 constraint is only for the application processor "V" extension for the app profile - not for embedded vectors which can have VLEN=32. From spec Introduction: ' The term base vector

It seems that restriction of minimum LMUL=2 would be half number of vector registers and LMUL=4 would be 8 vector registers. Thang

Hi Bruce, “I an not a fan of the vslide instructions. It seems they expose the size of the vector registers in a very unfortunate way. In particular they break down if VLEN=1. Most code would be

I think the concern here is lack of a clearly defined data layout pattern for such cases. eg, should the LSBs be in the odd or even register half, or should it be implementation-defined? Guy

For widening and narrowing instructions to work, the V spec depends upon changing SEW (to EEW) and LMUL (to EMUL), such that EEW/EMUL == SEW/LMUL. That is, to change the element size (widen or

It’s actually not fundamental to the ISA design that VLEN >= ELEN. An implementation with VLEN=32 could support SEW=64 whenever LMUL >= 2. This approach starts to pose code-generation headaches, but

OK, so it seems that to run our software (which Tony Cole referred to) we need VLEN>=64 for our embedded application. Is there any scope for reducing the number of V registers? Could RV32E_Vmin have

I an not a fan of the vslide instructions. It seems they expose the size of the vector registers in a very unfortunate way. In particular they break down if VLEN=1. Most code would be better off

So, (on a 32x 32-bit vector register machine) the widening and narrowing instructions can use 64-bit elements (for destination and source respectively), but not any of other instructions, correct?

Allowing VLEN<128 would allow for smaller vector register files, bit it would also result in a profile that is not forward-compatible with the V spec. This would produce another fracture the software

Note that the effective LMUL is limited to 8, the same as the actual LMUL, so if you've set e32m4 (32 bit elements with LMUL=4) then you can only widen to 64 bit results, not 128 bit.

Yes. The Standard Element Width (SEW) would be limited to 32 bits, but the widening multiplies and accumulates produce the same number of wider results using multiple registers (higher effective

Having 32x 32 bit registers with LMUL=4, giving 8x 128 bits - does this allow for 64-bit elements? I don't think it does, but it’s not clear in the spec. I use 64-bit elements for “wide”

There is nothing to prevent implementing 32x 32 bit registers on a 32 bit CPU. The application processor spec has quite recently (a few months) specified a 128 bit minimum register size but I don't