riscv-profiles VS riscv-v-spec

Ssstrict is supposed to address the undefined behaviour problem, or at least it'll make undefined instructions actually trap.

https://github.com/riscv/riscv-profiles/blob/main/rva23-prof...

>there are a lot of incompatible ISA implementations of RISC-V

This is common FUD.

In reality, most chips in the market, including all known application processors, follow the RVA profile[0] spec.

So do Linux distributions.

0. https://github.com/riscv/riscv-profiles/releases

The bit manipulation [0] extension has been ratified for a while now and is part of the RVA22 application extension profile [1].

You can already buy SOCs that support it, e.g. vision five 2 and star64.

Interestingly the risc-v vector has it's own popcount instructions for vector registers/register masks. This is needed, because the scalable architecture doesn't guarantee that a vector mask can fit into a 64 bit register, so vector masks are stored in a single LMUL=1 register. This works really well, because with LMUL=8 and SEW=8 you get 100% utilization of the single LMUL=1 vector register.

Another interesting thing is that the vector crypto extension will likely introduce a element wise popcount instruction.

[0] https://github.com/riscv/riscv-bitmanip/releases/download/1....

[1] https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

That's why we have RISC-V profiles.

Yeah more or less. They now have RISC-V Application Profiles which are basically minimum requirements for "application processors" - essentially devices like phones where you might want to distribute binary apps.

The Profiles spec which includes RVA22 was finally ratified[0] last week.

0. https://github.com/riscv/riscv-profiles/releases/tag/v1.0

Context: RISC-V profiles spec got ratified last week.

Yeah unfortunately there isn't really a great place that lists all the extensions with links and ratification status.

But anyway there is a sort of standard set of extensions that "application processors" (I guess CPUs that want to run precompiled code) should support:

https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

The 22 indicates the year.

Ah, you're right: https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

That's good to see. (Boy, it's really hard to find info about RISC-V profiles on Google. It just seems to ignore all the letters and numbers.)

Here are some resources I can recommend:

RVV spec (also look at the examples in the repo): https://github.com/riscv/riscv-v-spec/blob/master/v-spec.ado...

RVV intrinsics viewer: https://dzaima.github.io/intrinsics-viewer

Tutorial: RISC-V Vector Extension Demystified (3 hour video going over every instruction): https://youtu.be/oTaOd8qr53U

RISC-V Vector extension in a nutshell: https://fprox.substack.com/p/risc-v-vector-extension-in-a-nu...

If you want to see a more complex example/real world application, then you might also be ibterested ib my article about vectorizing unicode conversions: https://camel-cdr.github.io/rvv-bench-results/articles/vecto...

In terms of development I'd recommend using qemu and a cross compiler, or if you want hardware try to get the kendryte k230 (currently the only sbc with rvv 1.0 support) or wait a bit for better hardware (BPI-F3 and sg2380 should release this year).

And this isn't just some theoretical or something unlikely to happen - the official spec already contains such a bug. If the writers of the spec can't get things right, even with the small amount of code in the spec, I don't have high hopes that less informed programmers will. RVV being absurdly complicated (IMO, compared to SVE2 and AVX10) doesn't help its cause here.

Will the reference one actually be the most optimal one on future hardware?

I'll do a deep dive into the https://gms.tf/riscv-vector.html#getting-started tutorial, and probably pop the proverbial stack and just study RVV 0.7.1 on its own (using https://github.com/riscv/riscv-v-spec/releases/tag/0.7.1).

I see your point. You can file a request for it at https://github.com/riscv/riscv-v-spec/issues if you want to pitch it to the relevant ISA bodies. The bar for implementing it pretty high.

It's not "unusual"; using data registers for mask is a valid tradeoff especially for low-end implementations, whereas higher-end architectures can easily use shadow registers. Discussed in depth at https://github.com/riscv/riscv-v-spec/issues/811