9 ms·

Will RISC-V Revolutionize Computing?

35 points by signa11 6y ago

ncmncm 6y ago
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.
- davekeck 6y ago
  > - 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.
- Pet_Ant 6y ago
  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.
  - ncmncm 6y ago
    "As slim as possible" includes popcount and rotate, along with add and shift, if you seriously mean for a design to be useful.
- magicalhippo 6y ago
  Just curious, why rotate and popcount? It's been a while since I did any serious asm, so a bit rusty.
  - ncmncm 6y ago
    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.
- avianes 6y ago
  > - 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.
- deleted 6y ago
  [deleted]
klelatti 6y ago
I like the idea of RISC-V, applaud the designers and wish it well, but there is a lot of slightly purple prose here about the benefits of an open and 'free' ISA. I can see how RISC-V works for SoC designers who either 1. Want to cut costs to a minimum or 2. Want to add their own proprietary extensions to distinguish it from the competition. I'm less sure that it works for everyone else. The instruction set running on your Raspberry PI is the same as that running on your iPhone which in turn is the same as that running on an Ampere Server. Do we really want to be faced with a multiplicity of distinct ISAs?
- melling 6y ago
  More competition means more innovation and lower prices. The compiler abstracts the instruction set for most people.
  - klelatti 6y ago
    I'm old enough to remember when there was a lot of ISA competition. Trouble was each ISA had no longevity, you were dependent on one vendor typically and choosing an ISA was pot luck. I don't think it's reasonable to expect compiler writers to solve any fragmentation issues. As I said I like RISC-V and think it's laudable. We just need to recognise the downsides and not get too carried away.
    - d_tr 6y ago
      It is definitely a must to try and find downsides and weigh them, but even with RISC-V thrown into the mix, the situation will be far from what it was 25 - 35 years ago, and in addition the tools are much more advanced. Modern compilers can already deal with several permutations of ISA extensions. Of course, there are limits to everything, so having everyone and his grandma creating his own extension will be messy / ugly...
      - klelatti 6y ago
        Very much agree!

35 points by signa11 6y ago

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.

davekeck 6y ago
> - 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.
Pet_Ant 6y ago
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.
- ncmncm 6y ago
  "As slim as possible" includes popcount and rotate, along with add and shift, if you seriously mean for a design to be useful.
magicalhippo 6y ago
Just curious, why rotate and popcount? It's been a while since I did any serious asm, so a bit rusty.
- ncmncm 6y ago
  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.
avianes 6y ago
> - 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.
deleted 6y ago
[deleted]

klelatti 6y ago

I like the idea of RISC-V, applaud the designers and wish it well, but there is a lot of slightly purple prose here about the benefits of an open and 'free' ISA. I can see how RISC-V works for SoC designers who either 1. Want to cut costs to a minimum or 2. Want to add their own proprietary extensions to distinguish it from the competition. I'm less sure that it works for everyone else. The instruction set running on your Raspberry PI is the same as that running on your iPhone which in turn is the same as that running on an Ampere Server. Do we really want to be faced with a multiplicity of distinct ISAs?

melling 6y ago
More competition means more innovation and lower prices. The compiler abstracts the instruction set for most people.
- klelatti 6y ago
  I'm old enough to remember when there was a lot of ISA competition. Trouble was each ISA had no longevity, you were dependent on one vendor typically and choosing an ISA was pot luck. I don't think it's reasonable to expect compiler writers to solve any fragmentation issues. As I said I like RISC-V and think it's laudable. We just need to recognise the downsides and not get too carried away.
  - d_tr 6y ago
    It is definitely a must to try and find downsides and weigh them, but even with RISC-V thrown into the mix, the situation will be far from what it was 25 - 35 years ago, and in addition the tools are much more advanced. Modern compilers can already deal with several permutations of ISA extensions. Of course, there are limits to everything, so having everyone and his grandma creating his own extension will be messy / ugly...
    - klelatti 6y ago
      Very much agree!