Added explicit statement to spec for this case. There was a wrap-around statement for single-width but not for widening reductions. Krste | As a 2*SEW scalar from element 0 of vs1 is added to the

As a 2*SEW scalar from element 0 of vs1 is added to the sum of the various SEW elements in vs2, even a vector of length 1 can cause overflow.

If the vector operand to an integer vwredsum is long enough, 2*SEW will not be large enough to contain the result. I would interpret the spec to suggest that the low 2*SEW bits are written to the

HI Bruce, The all-in-one QEMU and GNU toolchain will support the latest version of Vector spec. For the V extension v0.7.1, we are planning to run docker containers on Allwinner Nezha board directly,

Do you support RVV 0.7.1 as well as tracking 1.0? RVV 0.7.1 is the only version available in real mass-produced hardware at the moment, and probably for the next 12 to 18 months at a guess. I myself

It might be worth updating sections: 7.5 Vector Strided Instructions 7.6 Vector Indexed Instructions with the address calculations to specify the stride offsets and indexs and byte sized, rather than

Thanks for the suggestions. I tried to clean up and clarify this section: https://github.com/riscv/riscv-v-spec/commit/3cc98373f954df996c2d7973ef0fc38bc866f620 Krste | Hi, | Re-reading section

Hi Mick, As Jim said, you may need the right toolchain and right qemu for the version you want, which is not an easy task. BTW, the PLCT Lab is working on setting an all-in-one developer environment

Hi Mick, The vector 0.7.1 version has been implemented in T-Head Xuantie c910v CPU and AllWinner D1 Soc. If that's what you want or If you want to use the QEMU upstream currently, I can give you some

There are many thousands of different incompatible draft versions of the vector spec. If you don't have exactly matching versions of the compiler and qemu and libraries, it isn't going to work.

Hi Mick, I use the RISC-V Vector QEMU branch from SiFive (for 32-bit, don’t know about 64-bit support though): https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7-fix Also, there may

Does a known-good guide exist for building riscv64 qemu to be able to run Vector instructions? From the main qemu repo, we are to build the riscv64-softmmu target and run the 64-bit Buildroot Image,

Hi, Re-reading section 3.3.2 in the documentation (link), would like to propose adding goal, constraints, steps for implementing Fraction LMUL I think adding these would really help clarify both

I see that section 7.5 of the vector spec currently says: When rs2=x0, then an implementation is allowed, but not required, to perform fewer memory operations than the number of active elements,

FYI, I'm working with Elisa Sawyer and others on a style and content guide for extension proposals, mostly based on the excellent bitmanip v1.0.0-rc1 draft. That draft includes a table like the one

Hi Krste, The descriptions of Zvl* look good. A couple of comments: * The V description says vector length greater than or equal to 128. Should it instead refer to Zvl128b? * I wonder if there

I added vector length extensions to spec. Please review, Krste | Hello Guy, | It definitely would be good for Zve to be a strict subset of V. I think that means the same thing as that any binary

Date: 2021/07/09 Task Group: Vector Extension Chair: Krste Asanovic Vice-Chair: Roger Espasa Number of Attendees: ~12 Current issues on github: https://github.com/riscv/riscv-v-spec We had a short

Hello Guy, It definitely would be good for Zve to be a strict subset of V. I think that means the same thing as that any binary that runs on Zve will run correctly on Z. But I’m not seeing how

Hi, The way 18.1 and 18.2 currently read in the V spec is a bit confusing. It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor". 1)