5 ms·

> - 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 0xFFF

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

ncmncm 6y ago
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.
- klyrs 6y ago
  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.
  - avianes 6y ago
    > 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-0.92.pdf 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.
    - klyrs 6y ago
      Agreed, all that's better than my hacks.
    - ncmncm 6y ago
      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.
      - avianes 6y ago
        > 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.
      - klyrs 6y ago
        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!

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

ncmncm 6y ago

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.

klyrs 6y ago
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.
- avianes 6y ago
  > 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-0.92.pdf 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.
  - klyrs 6y ago
    Agreed, all that's better than my hacks.
  - ncmncm 6y ago
    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.
    - avianes 6y ago
      > 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.
    - klyrs 6y ago
      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!