Five Good Things About RISC-V | Hacker News Reader

Five Good Things About RISC-V

codasip.com

18 pointstaubek15 comments

Open articleView on HN

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

Wishfull thinking that RISC-V will take off and not be uncumbered with proprietary extensions.

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

I was interested more in "rapidly" part.

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

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.

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.

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

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.

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

Clang multiversioning:

https://clang.llvm.org/docs/AttributeReference.html#cpu-disp...

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

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.

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.

Keyboard controllers but those generic shmoll boards are used for other things too with all their GPIOs and usb-c connector.

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.

Reply on news.ycombinator.com