riscv-sbi-doc VS riscv-bitmanip

The SBI spec[0] is not a long read.

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

>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

Well that's a very good question. At the moment the reality is something of a mess, because someone looked at Arm and though that must be a good idea. Plus the RISC-V Foundation has even less control over implementers than Arm does (which doesn't have a lot).

The good news is that the foundation is defining various platform specs. For servers it'll include a standard firmware spec plus open source firmware implementation and a few other bits. Maybe working UEFI one day. (https://lists.riscv.org/g/tech-unixplatformspec https://github.com/riscv-non-isa/riscv-sbi-doc)

The SBI (Supervisor-Binary Interface) is the API used by S-mode software (your operating system) to communicate with M-mode, and abstract away some hardware-specific details. It handles things like communicating between harts, power management, and performance monitoring. On real hardware, it is implemented by M-mode software. For VMs, it is typically implemented by the hypervisor. It's roughly analogous to the PSCI in ARM. For more information, have a look at the spec.

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

According to latest version of spec on GitHub (https://github.com/riscv/riscv-bitmanip) Bit-manip is in frozen state. Is this ratified and not updated in the sepc document or is it actually frozen?

I guess 0x20a52533 is a specific _zba instruction? Which one? I searched for "001000" (the left 6 bits of 0x20) in https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf , but couldn't find a match? Might be PEBKAC.

RISC-V does have a proposed extension Zbb that includes the cpop and cpopw instructions. It doesn't seem to have much recent activity, though.

https://github.com/riscv/riscv-bitmanip/blob/main/bitmanip/i...

Enabling B use in dynamically linked libc code will improve every application, especially for example use of orc.b in the C string functions, which is what I invented it for https://github.com/riscv/riscv-bitmanip/issues/41 (using V is even better, but that's optional in RVA22)

[2] https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0

There was a pick instruction, literally named cmov, in an older version of the B (bitmanip) extension (all the good stuff is in extensions). But it seems like it got canned or something, it's not in it anymore (various other interesting instructions were also lost). Silly if you ask me, but I haven't kept up with any of the debate, maybe there's a decent reason..

Yoe maybe interested in the just ratified "RISC-V Bit-Manipulation ISA-extensions" https://github.com/riscv/riscv-bitmanip/releases/download/1....