4 ms·

Five Good Things About RISC-V

18 points by taubek 4y ago

DeathArrow 4y ago
>5. THE RISC-V ECOSYSTEM IS GROWING RAPIDLY Is there a desktop class CPU and a server class CPU in RISC-V space which can compete for money with X86 and ARM? If not, the how much time it will take? I'm trying to understand what "growing rapidly" means.
- pjmlp 4y ago
  Wishfull thinking that RISC-V will take off and not be uncumbered with proprietary extensions.
- oytis 4y ago
  "Growing" is a trend, first derivative, not today's snapshot. It's starting from embedded, both MCUs and Linux-capable MPUs, and already completes pretty well there. Desktop and server will take time, like it was with ARM too.
  - DeathArrow 4y ago
    I was interested more in "rapidly" part.
    - oytis 4y ago
      Well, what I can see in embedded area is that quite recently a lot of interesting (chinese of course) RISC-V chips have appeared at price points where ARM ones can hardly compete, especially given the never-ending chip shortage
- avianes 4y ago
  Building a x86/ARM/RISC-V desktop or server class CPU core is more about the microarchitecture. And RISC-V is an ISA, which is a part of the architecture not the microarchitecture. "Ecosystem" here refers to: the compilers and tools, supported OS, the suggested ISA extensions, the research movements who work and experiment with it, and so on.
pencilguin 4y ago
All the optional extensions will make writing portable code practically impossible. What is an optimization on one chip will be a crushing pessimization on another, if it runs at all. I gather they have started to publish "profiles" that might rein in the worst of this. And the profile meant for desktop workstation use appears to have "popcount" and a few other concessions. But, unlike in the x86, ARM, or POWER worlds, where we have the notion of a generation on a timeline, nothing like that helps contain the complexity of development targets. Each extension is its own extra dimension to be used or compensated for lack of, separately. I have not seen any chip with a popcount instruction yet, but have not checked this year.
- drpixie 4y ago
  Agreed - unfortunately many extensions going in too many directions. It might be more practical to require extensions to conform to a hierarchy, so if you implement Z, you must also implemented X and Y. Given the low cost of transistors, it seems parsimonious to be defining lots of incompatible variations on the RISC-V theme. Look at the ARM market, with minor variations in the number of timers and IO pins, most chips follow one of only a few common directions - eg. we've got small bit-pushing chips as controllers, and larger chips with FP and MMU for "computers".
  - yummypaint 4y ago
    I am hoping the diversity of extensions will help spur development of more general and adaptable ways of using different computing hardware. I think these are innevitable growing pains coming from an era where all the design decisions were made by just a few players. I would argue some of standardization in the arm market has alot to do with the business desire to fit products into pre-defined niches that don't compete with each other.
- vardump 4y ago
  Nothing prevents compilers from compiling in multiple paths for anything performance critical. That's how it's already being done on x86. If AVX-512 is available, use it. If not, maybe fall back to AVX-2. Else fall back to SSE2. Etc. GCC multiversioning: https://gcc.gnu.org/wiki/FunctionMultiVersioning https://gcc.gnu.org/wiki/FunctionMultiVersioning Clang multiversioning: https://clang.llvm.org/docs/AttributeReference.html#cpu-dispatch https://clang.llvm.org/docs/AttributeReference.html#cpu-disp...
sylware 4y ago
I want a shmoll 64bits risc-v (+ a USB block + timer and certainly a few other blocks) board with only tons of GPIOs and 1 USB-C connector. The arm world is able to provide those, but the risc-v galaxy always adds bluetooth/wifi/AI/etc. Goal: USB keyboard firmware directly in 64bits risc-v assembly. (I have such boards, but with 32bits risc-v cores and I am unable to self-motivate myself to go 32bits assembly, even knowing there are provisions for 32bits<->64bits ports in risc-v). I guess, I'll have to go for those overkill boards.
- benj111 4y ago
  Why do you want 64bit specifically, for a keyboard controller? I've not tried making one, I struggle to think what you would need to do over and above 8bits even.
  - sylware 4y ago
    Keyboard controllers but those generic shmoll boards are used for other things too with all their GPIOs and usb-c connector.
benj111 4y ago
Aren't most of these basically restating the 'open' element? I get that it's good, but I don't think it deserves 4 of the 5 different reasons. I assume the title was written first (5, V, gettit?) But the author couldn't actually think of 5 reasons
jbirer 4y ago
Sadly evil Chinese companies like Allwinner are already moving in to benefit from the freedom of RISC-V while still doing things like locking the firmware and bootloader, producing something that is not too different from current locked-in ARM devices.

18 points by taubek 4y ago

>5. THE RISC-V ECOSYSTEM IS GROWING RAPIDLY Is there a desktop class CPU and a server class CPU in RISC-V space which can compete for money with X86 and ARM? If not, the how much time it will take? I'm trying to understand what "growing rapidly" means.

pjmlp 4y ago
Wishfull thinking that RISC-V will take off and not be uncumbered with proprietary extensions.
oytis 4y ago
"Growing" is a trend, first derivative, not today's snapshot. It's starting from embedded, both MCUs and Linux-capable MPUs, and already completes pretty well there. Desktop and server will take time, like it was with ARM too.
- DeathArrow 4y ago
  I was interested more in "rapidly" part.
  - oytis 4y ago
    Well, what I can see in embedded area is that quite recently a lot of interesting (chinese of course) RISC-V chips have appeared at price points where ARM ones can hardly compete, especially given the never-ending chip shortage
avianes 4y ago
Building a x86/ARM/RISC-V desktop or server class CPU core is more about the microarchitecture. And RISC-V is an ISA, which is a part of the architecture not the microarchitecture. "Ecosystem" here refers to: the compilers and tools, supported OS, the suggested ISA extensions, the research movements who work and experiment with it, and so on.

pencilguin 4y ago

All the optional extensions will make writing portable code practically impossible. What is an optimization on one chip will be a crushing pessimization on another, if it runs at all. I gather they have started to publish "profiles" that might rein in the worst of this. And the profile meant for desktop workstation use appears to have "popcount" and a few other concessions. But, unlike in the x86, ARM, or POWER worlds, where we have the notion of a generation on a timeline, nothing like that helps contain the complexity of development targets. Each extension is its own extra dimension to be used or compensated for lack of, separately. I have not seen any chip with a popcount instruction yet, but have not checked this year.

drpixie 4y ago
Agreed - unfortunately many extensions going in too many directions. It might be more practical to require extensions to conform to a hierarchy, so if you implement Z, you must also implemented X and Y. Given the low cost of transistors, it seems parsimonious to be defining lots of incompatible variations on the RISC-V theme. Look at the ARM market, with minor variations in the number of timers and IO pins, most chips follow one of only a few common directions - eg. we've got small bit-pushing chips as controllers, and larger chips with FP and MMU for "computers".
- yummypaint 4y ago
  I am hoping the diversity of extensions will help spur development of more general and adaptable ways of using different computing hardware. I think these are innevitable growing pains coming from an era where all the design decisions were made by just a few players. I would argue some of standardization in the arm market has alot to do with the business desire to fit products into pre-defined niches that don't compete with each other.
vardump 4y ago
Nothing prevents compilers from compiling in multiple paths for anything performance critical. That's how it's already being done on x86. If AVX-512 is available, use it. If not, maybe fall back to AVX-2. Else fall back to SSE2. Etc. GCC multiversioning: https://gcc.gnu.org/wiki/FunctionMultiVersioning https://gcc.gnu.org/wiki/FunctionMultiVersioning Clang multiversioning: https://clang.llvm.org/docs/AttributeReference.html#cpu-dispatch https://clang.llvm.org/docs/AttributeReference.html#cpu-disp...

sylware 4y ago

I want a shmoll 64bits risc-v (+ a USB block + timer and certainly a few other blocks) board with only tons of GPIOs and 1 USB-C connector. The arm world is able to provide those, but the risc-v galaxy always adds bluetooth/wifi/AI/etc. Goal: USB keyboard firmware directly in 64bits risc-v assembly. (I have such boards, but with 32bits risc-v cores and I am unable to self-motivate myself to go 32bits assembly, even knowing there are provisions for 32bits<->64bits ports in risc-v). I guess, I'll have to go for those overkill boards.

benj111 4y ago
Why do you want 64bit specifically, for a keyboard controller? I've not tried making one, I struggle to think what you would need to do over and above 8bits even.
- sylware 4y ago
  Keyboard controllers but those generic shmoll boards are used for other things too with all their GPIOs and usb-c connector.

benj111 4y ago

Aren't most of these basically restating the 'open' element? I get that it's good, but I don't think it deserves 4 of the 5 different reasons. I assume the title was written first (5, V, gettit?) But the author couldn't actually think of 5 reasons

jbirer 4y ago

Sadly evil Chinese companies like Allwinner are already moving in to benefit from the freedom of RISC-V while still doing things like locking the firmware and bootloader, producing something that is not too different from current locked-in ARM devices.