alt Hacker NewsHaving written a few RISC-V cores, worked on a chip design project that used RISC-V cores, and generally being OK with the architecture in real-world use cases:
What the heck is this guy's problem? Just about every thing he mentioned as a problem is not a problem in practice. Too many options? Who cares, you're not trying to write code that runs on every possible configuration. Either you're writing embedded firmware and know exactly what core you're using, or you're writing an application that runs in an operating system and that system has a minimum ABI like RVA20 or whatever.
Array accesses take an extra instruction? Either you're in a tight loop walking a tiny array and you don't do the full offset calculation per step, or you're walking over an array in RAM and you're bottlenecked by the memory bus.
Hell, 90% of his arguments are "You can't detect X at runtime from user code without relying on some extension" - Yes, that is totally fine. Either you know your target CPU, or you don't - and then you ask your OS for details. This is not some dealbreaker.
From the article - "For example, if you are writing a kernel and want it to support all RISC-V cores" - NOBODY IS DOING THAT. You target a platform spec, not the combinatorial explosion of everything from RV32E to RVA22 or whatever the latest is.
You want to distinguish S mode from M mode? WHY DO YOU NOT ALREADY KNOW THIS?
Instruction encoding is weird? WHO CARES, the decoding is like eight lines of Verilog.
"Who can predict how their binary will act when a floating point store silently becomes a double-register move or a jump instruction, or vice-versa?" - THIS DOES NOT HAPPEN IN PRACTICE.
Guhhhhh, I don't get it. This guy has some vendetta and either has not shipped any risc-v code or is just in love with his own personal favorite instruction set.
Replies
Yeah the OP post read to me like someone throwing the baby out with three drops of bath water. If this was presented more like “minor gripes with risc V” I’m guessing I wouldn’t feel that way
Either you're writing embedded firmware and know exactly what core you're using, or you're writing an application that runs in an operating system and that system has a minimum ABI like RVA20 or whatever.
Array accesses take an extra instruction? Either you're in a tight loop walking a tiny array and you don't do the full offset calculation per step, or you're walking over an array in RAM and you're bottlenecked by the memory bus.
"Who can predict how their binary will act when a floating point store silently becomes a double-register move or a jump instruction, or vice-versa?" - THIS DOES NOT HAPPEN IN PRACTICE.
Thanks for this. RISC-V brings out the armchair critics for some reason.
The encoding being oddball does have some effects on linkers/loaders though I imagine?
Not that linking/loading is a super hot path people generally worry about.
> NOBODY IS DOING THAT.
RePalm kernel is literally that.
> Array accesses take an extra instruction? Either you're in a tight loop walking a tiny array and you don't do the full offset calculation per step, or you're walking over an array in RAM and you're bottlenecked by the memory bus.
I'm not a hardware person, but whenever I look at compiler output I find computed index accesses all over the place in the assembly. This would suggest to me that at least compiler developers believe these addressing modes to be important.
> Yes, that is totally fine. Either you know your target CPU, or you don't - and then you ask your OS for details.
So then my code has to choose between being hardware-dependent or OS-dependent? That doesn't seem ideal.
> "For example, if you are writing a kernel and want it to support all RISC-V cores" - NOBODY IS DOING THAT.
I'd hate to live in a future where linux distros need to ship a separate kernel binary for every random combination of RISC-V features. That said maybe the run-time feature-detection extension will be so widely supported in practice that this wouldn't come up?