> - represent bool `true` with ~0 in the ABI
So `true` would be 0xFFFFFFFF (assuming 32 bit)? Can you explain the advantage of that? Presumably 0 through 0xFFFFFFFE would be considered false?
So `true` would be 0xFFFFFFFF (assuming 32 bit)? Can you explain the advantage of that? Presumably 0 through 0xFFFFFFFE would be considered false?
The merit in `true` being 0xff...f is that, ANDed with X, it yields X. We see this logic applied with resounding success in GPUs and AVX instructions, where a multiword comparison sets corresponding lanes of a destination register to all zeroes or all ones. It is nothing short of bizarre that RISC-V architects (apparently) never heard about this.
In RISC-V, the instruction that sets a register to the result of a comparison sets it to 0 or 1, but 1 is (almost) useless. It has to be negated, and often then copied and inverted too, before it's useful.
a = (x & c) | (y & ~c)
Personally I'd probably be just as happy with operations that spams the first bit out to a full word, along with ANY / ALL to reverse that; but I'm with ya, this is a really important consideration.
> is a branch-free conditional assignment, and only works with c = 0 or ~0.
Using this hack only makes sense if there is no "conditional move". But the bitmanip risc-v extension offers a "conditional move" (cmov) [1]. With the addition of this operation there's no longer a need to use "0/-1" instead of "0/1".
[1]: https://github.com/riscv/riscv-bitmanip/blob/master/bitmanip... page 36
PS: You may notice that there's also an operation (cmix: conditional max) to do what you're suggesting: rd = (rs1 & rs2) | (rs3 & ~rs2) Which allows to mix the bits of two registers.
The notion that basic bit manipulation primitives are an obscure optional feature is a serious problem in the RISC-V process.
That's the whole idea of an extension. You may or may not include it depending on your needs.
> And there are no bitmanip extensions in any existing chips
RISC-V is a big project, and it is not yet complete. Some extensions are completed and some are not. The bitmanip extension is not finished yet, so it's understandable that it hasn't yet been integrated into chips.
> may never be in any future chips
Where did that statement come from?
> The notion that basic bit manipulation primitives are an obscure optional feature is a serious problem in the RISC-V process.
Bit manipulation is not an "obscure optional feature", but an "optional feature" just like the other extensions.
Please explain why this is a problem?
You're just blaming RISC-V without any argument there.
It sounds like you've identified a niche that isn't filled -- perhaps you could "corner the market" taking advantage of the SkyWater / Google offering. A risc-v microcontroller with the bitmanip extensions would be very cool, and its existence could prompt compilers to start targeting it. Go for it!