riscv-gnu-toolchain VS riscv-v-spec

> no absurdely and grotesquely massive and complex compilers anywhere

Absence of evidence is not evidence of absence, and anyway there's not even an absence: https://github.com/riscv-collab/riscv-gnu-toolchain https://llvm.org/docs/RISCVUsage.html

> feature creeps on computer language syntax nowhere to be found

At least one of us is very confused, and in case it's me, how do language details matter to RISC-V?

I then looked at the .cargo/config.toml provided by the guide and saw that it wasn't actually statically compiling the code. After a bit of tinkering and building my own toolchain from here, I ended up with this config.toml file:

b) collabriscv - essentially gcc 12.2 + binutils master/2.40 as per https://github.com/riscv-collab/riscv-gnu-toolchain

Or would it be better to take what is in https://github.com/riscv-collab/riscv-gnu-toolchain which is gcc 12.2 and start from there?

I'm not able to build https://github.com/riscv-collab/riscv-gnu-toolchain.git like this:

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