That's true. :) Providing full support for Vector extension is already on the todo-list of CAS/PLCT Lab. Vector extension is one of the extensions that are included in an all-in-one developer

I’ve made a frozen release of version 1.0 ready for public review. The release is tagged: https://github.com/riscv/riscv-v-spec/releases/tag/v1.0 and I’ve attached pdf below. The main repo has

I don't do LLVM work, and can't offer any suggestions there. In general, I'd say that if you don't have a half dozen people doing assembler, compiler, simulator, kernel, library, etc work, then you

I see. I'm ashamed to admit, but I am now really lost between all the permutations of Vector ext. revisions and toolchain versions that I've attempted without success. At this point, I'd just like to

V-extension version 1.0 hasn't been frozen yet. Its second release candidate was posted just yesterday: https://github.com/riscv/riscv-v-spec/releases/tag/v1.0-rc2 I wouldn't expect toolchain support

Hello Jim, Where could I find the last clang build for v1p0? I've followed the instructions laid out here, which pulls from upstream LLVM: https://github.com/sifive/riscv-llvm But this e-mail appears

I've finally finished an extensive pass over the whole spec, and believe it should be ready for public review but given that it's late on a Friday, I would like to give at least one more sleep cycle

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