Hacker News Reader

Hacker News

Comment by ncmncm | Hacker News Reader

Parent Full thread

ncmncm

Me, I'm ready for a RISC-VI or RISC-W.

It would be quite a lot like RISC-V, except it would:

- have rotate instructions in the core set

- have popcount instructions in the core set

- represent bool `true` with ~0 in the ABI

- have all the add, subtract, and comparison instructions set two registers (in addition to the destination), one to 0 and the other to ~0, according to a test of the result.

- have conditional branch and conditional move designate a register to be tested for equality to zero. Conditional move would move from one of two register sources, either of which could be the same as the destination.

- have two ISA registers fixed at 0 and -1.

View on HN

> - have rotate instructions in the core set

> - have popcount instructions in the core set

There is the Bitmanip extension for that. Why it should be in the core ISA ? Microcontrollers don't always need it. The purpose of the extensions is to keep the core ISA as minimal as possible.

> - represent bool `true` with ~0 in the ABI

It only takes one operation to emulate this behavior when you need it. addi rd, rs, -1 (you also have to flip the comparison, but it doesn't cost anything) Can you justify that we need "0/-1" more often than "0/1"?

> - have all the add, subtract, and comparison instructions set two registers (in addition to the destination), one to 0 and the other to ~0, according to a test of the result.

Why ? Adding destination registers puts more pressure on the register bank and may limit future CPU designs. Do you have an argument to show that it's worth it despite the price?

> - have two ISA registers fixed at 0 and -1

Which piece of code would benefit from that? A good justification is required to remove a (non-constant) registre from the ISA. Anyway, RISC-V already allows you to do that. Just write "addi rd, x0, -1" at the beginning of your code then use the rd register as a -1 register.

Sorry, but why do you need it in the base set? If it’s a modular chip that also works for other applications then the base should be as slim as possible. As long as your targets all support it and likely any desktop chips would.

"As slim as possible" includes popcount and rotate, along with add and shift, if you seriously mean for a design to be useful.

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

It doesn't matter what other values are "considered". What matters is what value you get from a boolean operation, like op<.

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.

To spell that out one step further:

  a = (x & c) | (y & ~c)

is a branch-free conditional assignment, and only works with c = 0 or ~0.

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.

> a = (x & c) | (y & ~c)

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

Agreed, all that's better than my hacks.

There are no bitmanip extensions in the core instruction set where it is needed. And there are no bitmanip extensions in any existing chips, may never be in any future chips, and will likely not be in future microcontrollers if it ever does get adopted, so anything you find there is moot.

The notion that basic bit manipulation primitives are an obscure optional feature is a serious problem in the RISC-V process.

> There are no bitmanip extensions in the core instruction set where it is needed.

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's an open source ecosystem. This piece sounds important to you. Have you considered contributing?

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!

Just curious, why rotate and popcount? It's been a while since I did any serious asm, so a bit rusty.

popcount is the basis for a whole family of bitwise operations that are very slow without.

rotate is essential to modern crypto ciphers and efficient hashes.

Reply on news.ycombinator.com