Having 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.
It has an effect only in terms of how big an offset you can encode in a relative jump, the _arrangement_ of those bits in the instruction is irrelevant (and already abstracted away in the compiler/linker framework).
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
My disagreement with the article is mostly the following:
RISC-V is not an ISA, but an ISA generation framework.
If RISC-V would've standardized aarch64 1-to-1, the end result would've still been a huge extension mess, because a lot of people (RVI member) have different requirements and a very happy to build their own subsets, which would then be upstreamed because multiple vendors want the same subsets and compatibility between them. Obviously it would've been better, similar to if RISC-V spawned with RVA23 done, but development takes time and RISC-V International started, because people where already using RISC-V.
RISC-V also is the most DOSed ISA, with people proposing crazy stuff. Just the other day somebody proposed an instruction that would do up to 2^30 16-bit comparisons in one instruction at the largest VLEN. Because they wanted to improve their string processing usecase.
---
In my experience RVA23 matches aarch64 and x86 in uop count (without fusion), code density is better, instruction count is slightly higher. The biggest impact on the instruction count advantage of aarch64 over RVA23 is a single instruction, load-pair, which gets cracked at decode in every high-performance implementation, because it writes to to registers.
The Arm approach to code density is using multiple writeback instructions that have to be cracked and the RISC-V one is RVC. Both prohibit simple linear scaling of parallel decoding, so code density seems to have mattered to Arm enough to make the tradeoff worth it.
- A big problem with extension detection RISC-V has is that there's no central authority mandating vendors to not overlap things (obviously, given RISC-V being an open standard), so basic bitmasks for supported extensions is generally rather problematic (and of course even if you collected a standardized bitmask of all extensions from all vendors, it'd grow quite massive quite quickly); you'd at least want some grouping/marking by vendor, if not full extension strings. That said, it would be nice to at the very least have some standard in-memory blob format if nothing else, that you could query from any OS/libc. (which maybe somewhat-exists to some extent with a C API meant for libc, but as-is still doesn't attempt to figure out vendor extensions).
- many, if not the vast majority, of aarch64 TBZ/TBNZ are probably branching on a boolean; something RISC-V can also of course do in one instruction. Generally, comparing instruction frequencies across ISAs is messy if not approximately meaningless due to different sorts of things existing for solving the same tasks.
- "Having this happen means that instead of a clearly-understandable crash you get ... well ... anything." - RISC-V will do you one better - it doesn't even guarantee a crash when an instruction isn't defined at all! Overlapping extensions is definitely messy for disassembly, sure, but that's also just basically unavoidable as long as RISC-V is open (see my first point). (perhaps there could've been stricter rules for reserved-for-standard encodings than reserved-for-vendor ones? of course still doesn't help vendor encodings, nor non-compliant vendors)
I was excited when I heard about the project just after it started.
However, past experiences taught me to wait before getting excited about the new 'shiny thing'. I did it differently with RISCV. I waited.
I am glad I did.
It took a long time for actual silicon to appear.
Also, the silicon today has all the facepalming special cases mentioned in the article.
Its almost like those old soviet era cpus that had the list of bad instructions handwritten on the package.
Overall, RISCV was a minor spin on MIPS, but without really learning from other processors.
So why is everyone still pushing for it?
It has the words 'open' on it. People pattern match on that marketing.
As part of that marketing, they also pushed this attitude from the project... 'RISC won'.
I think Chester Lam said it best when he wrote his essay stating that RISC didn't win... OoO archs won. I couldn't articulate that nearly as well as he did.
If you haven't read it, I recommend it.
So, yeah, here we are.
Many people will follow the bandwagon, but they will find that RISCV will not make a significant difference.
I am glad we still have Arm (in all its many forms), x86, and others.
(btw, despite my username, I don't think x86 is the best either :-)
Also, if you aren't trying to ship a product, you can experiment with ISAs on an fpga.
Yes, fpgas are a lot slower, but they are also a lot more fun.
Especially with the great work done to create open source toolchains.
Heck, if you are really serious (slighly crazy), you can build your own chip.
For the foreseeable future ASIC shuttles are available at prices under $10k. (again, you have to be a little crazy)
I'd say RISC won, when you consider how "RISCy" x86 is[1] compared to the ur-CISCs (68k, VAX) that RISC projects were in opposition to.
[1] Not because of often-called "risc like" microcode engine, but because the most complex addressing mode on x86 usually decodes two microinstructions, and decodes in single cycle. In comparison VAX needed separate pipeline for instruction decoding.
Having 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.
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.
It has an effect only in terms of how big an offset you can encode in a relative jump, the _arrangement_ of those bits in the instruction is irrelevant (and already abstracted away in the compiler/linker framework).
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
My disagreement with the article is mostly the following:
RISC-V is not an ISA, but an ISA generation framework.
If RISC-V would've standardized aarch64 1-to-1, the end result would've still been a huge extension mess, because a lot of people (RVI member) have different requirements and a very happy to build their own subsets, which would then be upstreamed because multiple vendors want the same subsets and compatibility between them. Obviously it would've been better, similar to if RISC-V spawned with RVA23 done, but development takes time and RISC-V International started, because people where already using RISC-V.
RISC-V also is the most DOSed ISA, with people proposing crazy stuff. Just the other day somebody proposed an instruction that would do up to 2^30 16-bit comparisons in one instruction at the largest VLEN. Because they wanted to improve their string processing usecase.
---
In my experience RVA23 matches aarch64 and x86 in uop count (without fusion), code density is better, instruction count is slightly higher. The biggest impact on the instruction count advantage of aarch64 over RVA23 is a single instruction, load-pair, which gets cracked at decode in every high-performance implementation, because it writes to to registers.
The Arm approach to code density is using multiple writeback instructions that have to be cracked and the RISC-V one is RVC. Both prohibit simple linear scaling of parallel decoding, so code density seems to have mattered to Arm enough to make the tradeoff worth it.
Random minor-ish notes:
- A big problem with extension detection RISC-V has is that there's no central authority mandating vendors to not overlap things (obviously, given RISC-V being an open standard), so basic bitmasks for supported extensions is generally rather problematic (and of course even if you collected a standardized bitmask of all extensions from all vendors, it'd grow quite massive quite quickly); you'd at least want some grouping/marking by vendor, if not full extension strings. That said, it would be nice to at the very least have some standard in-memory blob format if nothing else, that you could query from any OS/libc. (which maybe somewhat-exists to some extent with a C API meant for libc, but as-is still doesn't attempt to figure out vendor extensions).
- many, if not the vast majority, of aarch64 TBZ/TBNZ are probably branching on a boolean; something RISC-V can also of course do in one instruction. Generally, comparing instruction frequencies across ISAs is messy if not approximately meaningless due to different sorts of things existing for solving the same tasks.
- "Having this happen means that instead of a clearly-understandable crash you get ... well ... anything." - RISC-V will do you one better - it doesn't even guarantee a crash when an instruction isn't defined at all! Overlapping extensions is definitely messy for disassembly, sure, but that's also just basically unavoidable as long as RISC-V is open (see my first point). (perhaps there could've been stricter rules for reserved-for-standard encodings than reserved-for-vendor ones? of course still doesn't help vendor encodings, nor non-compliant vendors)
What I like about RISC-V is not the ISA per se, but the ecosystem that has developed around it, particularly Chisel and CIRCT.
Specific choices for instruction encoding is less interesting, especially in the age of AI.
Ah rants from a non designer. So Patterson and crew, don't know what they are doing? Yeah hard pass.
100% agree with dmitrygr.
I was excited when I heard about the project just after it started. However, past experiences taught me to wait before getting excited about the new 'shiny thing'. I did it differently with RISCV. I waited. I am glad I did. It took a long time for actual silicon to appear. Also, the silicon today has all the facepalming special cases mentioned in the article. Its almost like those old soviet era cpus that had the list of bad instructions handwritten on the package.
Overall, RISCV was a minor spin on MIPS, but without really learning from other processors.
So why is everyone still pushing for it? It has the words 'open' on it. People pattern match on that marketing.
As part of that marketing, they also pushed this attitude from the project... 'RISC won'. I think Chester Lam said it best when he wrote his essay stating that RISC didn't win... OoO archs won. I couldn't articulate that nearly as well as he did. If you haven't read it, I recommend it.
So, yeah, here we are. Many people will follow the bandwagon, but they will find that RISCV will not make a significant difference.
I am glad we still have Arm (in all its many forms), x86, and others. (btw, despite my username, I don't think x86 is the best either :-)
Also, if you aren't trying to ship a product, you can experiment with ISAs on an fpga. Yes, fpgas are a lot slower, but they are also a lot more fun. Especially with the great work done to create open source toolchains. Heck, if you are really serious (slighly crazy), you can build your own chip. For the foreseeable future ASIC shuttles are available at prices under $10k. (again, you have to be a little crazy)
I'd say RISC won, when you consider how "RISCy" x86 is[1] compared to the ur-CISCs (68k, VAX) that RISC projects were in opposition to.
[1] Not because of often-called "risc like" microcode engine, but because the most complex addressing mode on x86 usually decodes two microinstructions, and decodes in single cycle. In comparison VAX needed separate pipeline for instruction decoding.
> slighly crazy
What a lovely euphemism.
Signed: someone slightly crazy.
I wonder if they will be inviting him to the next RISC-V design committee meeting.
For a friendly meeting, like Julius Caesar had on March 15, 44 BC.
"This time its different".