Comment by ethin
2 days ago
I can definitely see his argument, although I still do believe RISC-V did a lot of things better than x86...
I really do hope that the arch is eventually able to fix this. Better that there be an open ISA than them all be closed IMO.
Better than x86 is a low bar when ARMv8 exists.
And personally, I'm not even sure it crosses that bar.
RISC-V somehow manages to be more fragmented than x86 (which is impressive), and just can't compete on instruction density.
I think a large part of the issue with RISC-V is that it predates (public knowledge of) ARMv8 by a year or two, so it couldn't use it as inspiration. If you compare RISC-V to 32-bit ARM, the comparisons are much more favourable.
Everything I've seen is that rv64gc is very competitive with aarch64 wrt code density.
15 replies →
> think a large part of the issue with RISC-V is that it predates (public knowledge of) ARMv8 by a year or two
Does it? https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p... has a section on ARMv8 (section 2.5)
It says they became aware of it a year after they started the RISC-V project, but that’s five years before that paper was published.
1 reply →
>I still do believe RISC-V did a lot of things better than x86...
Such as? I can't think of anything it does better for high performance cores.
1B through 15B variable length instruction mess, for one. Which still yields a worse than average 4-5B per instruction average.
That is a strength, not a weakness. It allows for things like 64-bit immediate loads, 32-bit branch offsets, and nearly unlimited future extensibility.
With RISC-V, multiple instruction workarounds are needed for all of the above, and those sequences are usually sequentially dependent ones so they can't be run in parallel. i.e. the insanity of loading a 64-bit value through repeated 12-bit immediates with shifts, using multiple instructions to compute branch offsets, and RVV needing setvli instructions everywhere due to not having opcode space to encode vector length/type.
AArch64 is better, but still has problems with limited opcode space when it comes to future extensions. They've had to make "start mode" and "end mode" for SME to save on opcode space, and future compromises will likely be necessary.
Yeah...risc-v can learn from 50 years of x86 (among others). And yet.......
He has good points, except he misses the goal posts completely.