riscv-profiles VS riscv-platform-specs

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.)

For the higher end "Application" cores that do e.g. run Linux, there's a platform standardization effort. Refer to OS-A platform[0].

0. https://github.com/riscv/riscv-platform-specs/blob/main/risc...

>What does matter is standardization. For example a booting process.

Truth.

This is why RISC-V put a lot of effort on this, and put it early.

Relevant specs include but isn't limited to SBI[0], UEFI protocol[1] and the ongoing platform specification[2].

0. https://github.com/riscv-non-isa/riscv-sbi-doc/releases

1. https://github.com/riscv-non-isa/riscv-uefi/releases/tag/1.0...

2. https://github.com/riscv/riscv-platform-specs

For the record the RISC-V foundation already has a working group developing platform standards. Currently they have OS-A Server for servers, OS-A Embedded for small boards and the M platform for Zephyr/Linux NOMMU size systems. https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.pdf

The SBI console stuff are deprecated with no replacements. And if you checkout https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc, OS kernels really are expected to just find a 8250 or 16550 in the device tree, or as mentioned in a few other comments, use UEFI.

Platforms: https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc

There’s no indication of when the next iteration of the “Un” board will be, but it would be interesting to see if they’re targeting today’s tech, or something that’s around the corner such as the upcoming platform spec https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc

If you're building a chip for a server, workstation, cellphone you'll want to adhere to the platform spec.

RVA22[0] is the first one, and among other important things which go a long way to ease cross-vendor software compatibility, it does specify a set of extensions which are required.

[0]: https://github.com/riscv/riscv-platform-specs/blob/main/risc...

You’ll find the current RISC-V platform specification here.