Live data from Hacker News

RISC-V: They Should Have Known Better

dmitry.gr

111–120 of 467 posts

Re: RISC-V: They Should Have Known Better

#111
post #56
post #49

the significance and allure of risc-v, the reason china is investing heavily in it right now, has little to do with the technical details of how it works under the hood, it's the fact that it is an open standard not encumbered by intellectual property law. even if it isn't technically the best general-purpose processor architecture, it sets an important precedent by proving that it is possible to develop an open publ…

> it's the fact that it is an open standard not encumbered by intellectual property law. There are actually many of those. But Risc-V has become, through effective marketing, the Schelling point for anybody who wants to avoid the x86 and Arm ecosystems, both for the rent-seeking behaviors you mention, and also, in some instances, for security reasons. And, as others have mentioned, the ISA doesn't really matter. As l…

x86 is basically one big cabinet of horrors, but people seem to put up with it because it's "the standard." Then why not with RISC-V? Which is much if not infinitely better.

Re: RISC-V: They Should Have Known Better

#112
post #17
post #13

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.

Re: RISC-V: They Should Have Known Better

#113

> Say you want to store a byte to a register plus offset. What range of offsets can a [compressed] 16-bit instruction encode? Zero through three. If a compressed instruction could load or store a word to a word-scaled offset 0-3, relative to a register base address, that would be quite useful. It could be used for accesses to all structures four words or smaller.

In thumb, it can encode 0..31

Re: RISC-V: They Should Have Known Better

#114
post #68

Earlier quoted context omitted.

Has it been proven that no patent troll holds a patent covering RISC-V? Of course not because that's impossible to prove.

You might find this relevant: RISC-V Genealogy (2016) https://riscv.org/wp-content/uploads/2025/02/EECS-2016-6.pdf Or in poster form: https://riscv.org/wp-content/uploads/2025/02/RISC-V-Instruct...

Yeah, very much legally distinct MIPS, at least as a starting point.

The biggest tell is the mnemonics. While RISC-V takes a bunch of ideas from other places, and cleans things up, it copies a lot of mnemonics straight from MIPS.

But it also copies a lot of other ideas from MIPS, like the absolute distain for flag registers.

Re: RISC-V: They Should Have Known Better

#115
> The second category for big-compute is actual desktops and SBCs that do interactive computation, browsing, gaming, and other such "desktop work". I do not expect RISC-V to be a serious player at the top of this market. Simply put, the architecture is not designed for it, as pointed out above. Additionally, this market has the margins to afford licensing a much-better-designed aarch64 core from ARM, and gain proper support from a much larger corpus of software. Before you get your megaphone to shout about "openness", please note that the openness of the RISC-V spec is not relevant here at all, because an open spec does not magically materialize a well-designed out-of-order core for you for free. And if someone were to design a good out-of-order core, they would not be giving it away for free. An open spec does not mean every implementation is free.

I basically disagree with this. Not because this isn't the current state of things (it absolutely is), but because we're at a bit of an inflection point where mooore's law has proved itself to be an scurve, and we're very clearly well into the top half of it. From that, gate counts per core will also start to ossify, and that means the longer latency for getting an open core design off the ground initially will also start to make sense.

Re: RISC-V: They Should Have Known Better

#116
post #53

Earlier quoted context omitted.

X86 is the best argument that you can build a fast efficient RISC-V chip... because the X86 instruction set is a much bigger mess. It just blows my mind sometimes when designers don't learn insanely obvious lessons from the past, basic stuff like "complexity is evil" and "make the fast path overlap with the most common use cases" and "a standard with N optional extensions is actually N! (N factorial) standards." That…

> because the X86 instruction set is a much bigger mess. One of the things I've been playing with off and on in my spare time is poking at the x86 ISA. And yet, while the ISA does have some weirdness to it, it is a lot less weird than its reputation makes it out to be. For example, the sum total of the opcode form amounts to does-it-have-ModR/M + size of immediate operand (in bytes)... which honestly strikes me as si…

You've also got tons of prefixes with opcode dependent rules on what's allowed there, the opcode field itself is variable length (I've seen up to four bytes), you've got instructions that treat that immediate field as additional opcode bytes, etc.

Re: RISC-V: They Should Have Known Better

#117

> The second category for big-compute is actual desktops and SBCs that do interactive computation, browsing, gaming, and other such "desktop work". I do not expect RISC-V to be a serious player at the top of this market. Simply put, the architecture is not designed for it, as pointed out above. Additionally, this market has the margins to afford licensing a much-better-designed aarch64 core from ARM, and gain proper…

Whom do you expect to work for free to design you a state-of-the-art core?

Re: RISC-V: They Should Have Known Better

#118

Earlier quoted context omitted.

It's supposed to be impossible to prove a negative. But it might still happen some day. We just don't know.

"it's impossible to prove a negative" is a simplification. A negation is just the oppositive of an affirmation. If the affirmation is "there is an element E of an infinite set S that satisfies property P", the negation would be "there is no E in S that satisfy P", which would make proving by enumeration require checking every element of an infinite set, which is impossible. But other forms of proof might be possible.…

It was a joke I think.

Re: RISC-V: They Should Have Known Better

#119
post #74

Earlier quoted context omitted.

You can’t fix the mutually incompatible overlapping encodings in post.

They actually did do that. C was split into ZcfZcdZca, so you can choose a non-overlapping subset. It doesn't affect an RV32 non-F core anyway.

I… you can’t be serious.

Re: RISC-V: They Should Have Known Better

#120
post #112
post #17

Earlier quoted context omitted.

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.
Post reply on HN