The uppercase-V V extension is meant to cater to apps processors, where the VLEN >= 128 constraint is not inappropriate and is sometimes beneficial. But there's nothing fundamental about the ISA

Hi everyone, Are there any plans for a cut-down configuration of the vector extension suitable for embedded cores? It seems that the 32x128-bit register file is suitable for application class

yeeesh glad i don’t have to stare at that code too long. i know it’s not your code ... i think it could use a abs followed by a max reduction, then do the rest as scalar ops? these macros appear

Hi Guy, The code I've been looking at, uses this for a branch. FWIW: this is the SLEEF library (vector math library). An example of how it uses the check can be found at

It depends -- exactly what do you plan to do after determining if a mask is all-0 or all-1 or other? vpopc and vfirst can both special-case these common results via precomputation, so they both take

Er, nevermind, I got that wrong again. Roger's instruction can also early-out with slightly more complexity (if at least one 1 and at least one 0 is detected).

Yeah, it would've been more precise of me to have compared vpopc.m against Roger's hypothetical new instruction, which also must process all bits.

Actually, vfirst,m can be implemented with an early out on long temporal vector machines, whereas vpopc.m has to process all bits. If the common case for the input data is that all bits would be

Hi Andrew, thanks for the prompt and insightful answer. I'll use vpopc.m then. On 20/5/21 8:25, Andrew Waterman wrote: Indeed, my question was motivated while looking at some

I think this approach is sufficient, actually. On the machines I've worked on so far, vpopc.m is no slower than vfirst.m. For machines with very wide spatial vectors, you could imagine vpopc.m being

Hi all, I could not find any instruction that immediately computes this. Apologies if I missed the obvious here. Two options came to mind: vpopc.m and check whether

Excellent. Congratulations, and thank you!!

Hi, We would like to announce that the RISC-V V-extension v0.10 has been implemented in LLVM and the work has been committed upstream. Barcelona Supercomputing Center (BSC), Codeplay Software, and

There is a gcc RVV port from SiFive, but it has been dormant for months, and is not being actively maintained at the moment. You are better off using LLVM instead which is actively being worked on by

Hi Guy, The latest LLVM git repository should have support for all intrinsics except segment load/store. The intrinsics missed the branch window for the LLVM 12 release, but should be in LLVM 13 when

Hi, I’m starting a project where we want to use vector intrinsics and generate both 64b and 32b code (for RV64 and RV32). It looks line the best way to do this right now is with GCC, where we were

Yeah. I posted this link to our reddit /r/riscv four weeks ago and made a few comments about it. https://www.reddit.com/r/RISCV/comments/moz93r/arm_vs_riscv_vector_extensions/ It was posted on Hacker

I guess the publicity doesn't hurt, but I do wish the author had considered our developments here (at riscv/riscv-v-spec). His material appears to derive from Patterson-Waterman's 2017 book (and

https://erik-engheim.medium.com/arm-vs-risc-v-vector-extensions-992f201f402f Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can

Hi Tony: Could you create issues on github to track that? https://github.com/riscv/riscv-gcc Thanks :)