RISC-V: They Should Have Known Better • Hacker News Board

Re: RISC-V: They Should Have Known Better

#181

Post by camel-cdr » Sat, Aug 15, 2026, 9:17 AM UTC

phire wrote: post #163

monocasa wrote: post #146

Earlier quoted context omitted.

> I agree that 16-bit/32-bit variable length would struggle to beat x86. But I suspect it could have gotten close, simply because x86 wastes a huge amount of its advantage on legacy cruft. I'm saying the opposite. Maybe some theoretical CISC-V would leave RISC-V behind, but x86(and -64) makes wild choices for instruction density, and RV64GC already clearly beats x86-64 in .text density. > My secondary point, is that…

> and RV64GC already clearly beats x86-64 in .text density. Maybe I'm misremembering. Or maybe the numbers I'm remembering took into account the fact that most compilers unroll more aggressively on x86 than on targets they consider to be "embedded" (another pet peeve of mine) I stand by my assessment that the code density of rv64gc (and especially rv64g) is lower than it would be if they had actually put a focus on c…

> And maybe 16-32-48-64 is worth it..

It is, with a prefix encoding, you can reuse the RVC decode path 1-to-1 and get the 48/64-bit instruction starts with a simple bitshift (or simply handle the 48/64-bit instructions via the fusion path). This seems to be the encoding direction RISC-V is headed in.

Re: RISC-V: They Should Have Known Better

#182

Post by brucehoult » Sat, Aug 15, 2026, 9:18 AM UTC

imtringued wrote: post #170

brucehoult wrote: post #157

Earlier quoted context omitted.

> you can use the same base trick behind a carry lookahead adder YESSSS. I've been pointing this out for years and years. By the point that you're looking at the same propagation delay as a common 64 bit adder you're decoding 64 chunks of 16 bits per cycle. That's 128 bytes, or a 32-64 instructions wide decoder. That is so much wider than anyone is making or contemplating — or that even makes sense given the size of…

And even if you go to those extremes, the biggest nay sayer says the cost of the design flaw will require you to double the number of decoders, which hardly sounds like a big deal to me.

It's not even double, because half of them are RVC-only decoders.

Re: RISC-V: They Should Have Known Better

#183

Post by camel-cdr » Sat, Aug 15, 2026, 9:20 AM UTC

tsukikage wrote: post #21

hn_submit wrote: post #16

Why is he complaining about everything being optional in RISC-V? Isn't that the whole idea of RISC-V? The market can sort it out for themselves. RISC-V is already dominant in the MCU space despite its flaws, and many of them will be solved in due time. Most MCUs are used for dead-simple solutions, like electric blankets and microwaves with segment displays or LEDs. Whether their interrupts are handled in 44 or 22 cyc…

He explains, at length: there is no sane way to determine what the hardware you are running on actually supports, and so there is no sane way to ship compiled code that is both compatible and performant. We already had the mystery meat CPU wars several decades ago. We know how to make sane ISAs now and should be past that.

There is a very easy way to determine what hardware you are running on, it's the baseline of the OS.

Armv9-a doesn't mandate FP or SIMD support, but nobody does detection for those, why? Because it's required on the OS level. Similarly OS are moving their baseline to RVA23 so software can assume all of those instructions are available.

Re: RISC-V: They Should Have Known Better

#184

Post by camel-cdr » Sat, Aug 15, 2026, 9:24 AM UTC

Joel_Mckay wrote: post #34

mappu wrote: post #12

RVA23 hardware is available (e.g. SpacemiT K3)

Some are already on RVA23.1 even before the standard made it to more than 4 manufacturers product lines. The meme joke about standards is sadly relevant for riscv. =3 https://xkcd.com/927/

The RVA point releases don't add new mandatory features, so every RVA23 complient board is also RVA23.1 complient. They only add new optional extensions.

Re: RISC-V: They Should Have Known Better

#185

Post by camel-cdr » Sat, Aug 15, 2026, 9:27 AM UTC

Tuna-Fish wrote: post #87

eek2121 wrote: post #48

Earlier quoted context omitted.

ALL chip designs are an exercise of minmaxing these 3 variables: 1) power 2) performance 3) die area SOME chip designs also care about a 4th: 4) die area. NO design has the best of all...it is impossible since you have to trade 1 for another. The reason x86 has been dominate for so long is that is strikes a good balance across all areas, especially #4. A good balance is what you need for a good chip. EDIT: oh and you…

You forgot the variable that RISC-V chose to maximize: 5) Weird principles that are completely detached from anyone's actual needs and that are carried to a length similar to religious convictions. My biggest personal pet peeve about the architecture is the JAL instruction. That is, PC-relative jump and link immediate, which jumps to an PC + sign extended immediate value and stores the address of the next instruction…

https://github.com/riscv/riscv-isa-manual/pull/3269

Re: RISC-V: They Should Have Known Better

#186

Post by torginus » Sat, Aug 15, 2026, 10:30 AM UTC

wren6991 wrote: post #80

mhh__ wrote: post #65

Earlier quoted context omitted.

The ISA not mattering I think isn't as true when you account cost e.g. in a huge OOO cpu all the fusions and so on are afaict fairly doable but if you are on a cheaper / worse CPU all those extra bytes in the instruction stream do add up.

The RISC-V fusion arguments from back in ~2018 didn't really pan out. A lot of those fusion opportunities are just instructions now. slli + add? Zba (sh*add). slli + srli? Zbb (zext.*). slli + srai? Believe it or not, also Zbb (sext.*). Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are: * Taking up valuable compressed instruction space; each compressed codepoint has an opportu…

Sorry, haven't been following along, but sounds to me that the argument was a valid one seeing how it made the designers add new instructions.

Not sure if there's an impact caused by the late addition as opposed to always having them, but considering this is a fairly core thing what a program does, not sure what degree of fragmentation this causes on the level of compilers and hardware.

x86 effectively killed innovation in the SIMD space by making instruction set support so fragmented, that people had to target the decade-old lowest denominator.

Re: RISC-V: They Should Have Known Better

#187

Post by phendrenad2 » Sat, Aug 15, 2026, 10:59 AM UTC

Things are generally defined by the neccessities that led to their creation. x86 was designed for home PCs and has been forced to evolve with PC technology. ARM was designed to take advantage of RISC architecture, and were forced to evolve with the mobile industry. What was RISC-V invented for, and what external forces have acted on it since then?

Re: RISC-V: They Should Have Known Better

#188

Post by Joel_Mckay » Sat, Aug 15, 2026, 12:20 PM UTC

camel-cdr wrote: post #184

Joel_Mckay wrote: post #34

Earlier quoted context omitted.

Some are already on RVA23.1 even before the standard made it to more than 4 manufacturers product lines. The meme joke about standards is sadly relevant for riscv. =3 https://xkcd.com/927/

The RVA point releases don't add new mandatory features, so every RVA23 complient board is also RVA23.1 complient. They only add new optional extensions.

Until people admit they made the same mistake as ARM6 fragmenting the architecture focus, its adoption will probably continue to stall under each firms hubris. =3

https://en.wikipedia.org/wiki/Second-system_effect

Re: RISC-V: They Should Have Known Better

#189

Post by api » Sat, Aug 15, 2026, 3:29 PM UTC

monocasa wrote: post #131

inkyoto wrote: post #124

Earlier quoted context omitted.

> […] we're at a bit of an inflection point where mooore's law has proved itself to be an scurve […] Well. May's law[0], which states that: Software efficiency halves every 18 months, compensating Moore's Law. effectively counterbalances Moore's Law and, with continued technological process improvements and optimisations, the proverbial arm's race is likely to continue for a very, very long time – just a few days I w…

That's sort of orthogonal to what I'm saying. And the M5 doesn't have 500B transistors. We're well into the beginning of the ossification. Hell, it arguably started ~2006 with the end of dennard scaling leaving us with Tomasulo OoO cores being the design that makes the most sense for application cores, just getting wider over time as we get more gates.

Eventually CPUs and GPUs converge: huge numbers of CPUs with wide vector units.

Re: RISC-V: They Should Have Known Better

#190

Post by api » Sat, Aug 15, 2026, 3:30 PM UTC

monocasa wrote: post #122

dmitrygr wrote: post #117

Earlier quoted context omitted.

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

The same kind of people that 'worked for free' to develop Linux.

Linux is decent for its core use cases, but it is far from a solid pro-grade OS in a lot of areas... and in the areas it did get there, it took a long time to get there.