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

Re: RISC-V: They Should Have Known Better

#211

Post by water-drummer » Sat, Aug 15, 2026, 5:20 PM UTC

dreamcompiler wrote: post #138

spicyjpeg wrote: post #67

Earlier quoted context omitted.

RISC-V is in many aspects just legally-distinct-MIPS, from the base instruction set all the way up to how certain extensions introduce kludges that are very reminiscent of later MIPS additions. While I do somewhat agree on the fact it was a huge missed opportunity to improve upon MIPS's technical flaws in order to realistically compete against the likes of ARMv8, we still have to keep in mind that the primary driving…

> it still is a much better starting point than coming up with your own bespoke ISA 5 years ago I would have agreed with this but now I'm not so sure. We live in an era where you can tell a robot "Here's some C code. Design a 64-bit ISA, write the Verilog to implement it in an FPGA, write a C compiler for it, and use it to compile the C code I showed you earlier." And now your ISA and your compiler are part of your m…

Coming up with any ISA and coming up with a good or better ISA are two very different things.

Re: RISC-V: They Should Have Known Better

#212

Post by _0ffh » Sat, Aug 15, 2026, 5:22 PM UTC

phire wrote: post #114

wren6991 wrote: post #70

Earlier quoted context omitted.

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.

>absolute distain for flag registers

It's worst aspect maybe.

Re: RISC-V: They Should Have Known Better

#213

Post by amluto » Sat, Aug 15, 2026, 5:23 PM UTC

wren6991 wrote: post #203

amluto wrote: post #196

Earlier quoted context omitted.

In x86 land, there are, as a practical matter, four ISAs: real/v8086 mode, 16-bit protected mode, 32-bit protected mode, and 64-bit “long” mode. Machine code targeting one of these will be executed correctly by the CPU as long as the CPU is in the right mode. (Really it’s messier — there are the CS.D, CS.L, and SS.B bits plus the control bits for v8086, protected and long mode, but this barely matters.) Sure, this is…

> The fact that the relevant CPU features can’t even be enumerated in user mode just makes it worse. User-mode feature detection is usually used to select paths for acceleration instructions, like SIMD or crypto. The overlapping RISC-V instructions don't fit in that category: they're compressed versions of basic functions, mostly used in epilogs/prologs, which would be unconditionally compiled in. There are no overla…

At least with user-mode feature detection there could be an assertion that the correct feature set is present.

Re: RISC-V: They Should Have Known Better

#214

Post by Narishma » Sat, Aug 15, 2026, 5:28 PM UTC

mcdow wrote: post #202

dismalaf wrote: post #197

Earlier quoted context omitted.

It's not just China that has an interest. Multinational corporations also hate being charged licensing fees (see Qualcomm vs. ARM). Here's a list of RISC-V members: https://riscv.org/members/

lol the government of brazil is in there

Why is that funny?

Re: RISC-V: They Should Have Known Better

#215

Post by wren6991 » Sat, Aug 15, 2026, 5:29 PM UTC

coldtea wrote: post #210

wren6991 wrote: post #43

RISC-V is... fine. It satisfies my two requirements for an ISA as a hobby CPU designer, which are: 1. Supported in mainline LLVM and GCC. 2. I can implement it without lawyers sending me a love letter. Everything else, I can fix in post. There are enough good ideas spread across the extensions that I can assemble a reasonably put-together, curated embedded ISA with competitive performance and code density that admits…

> 2. I can implement it without lawyers sending me a love letter. What's stopping them? They can trivially claim it infringes any number of patents...

This is a good point, and of course this is why IP lawyers are so important: they protect you from other IP lawyers.

Re: RISC-V: They Should Have Known Better

#216

Post by chrisjj » Sat, Aug 15, 2026, 5:29 PM UTC

brucehoult wrote: post #154

gblargg wrote: post #46

Just noting, even if instructions were 100000000000000 bits long, reserving a single bit for 16-bit encoding would waste 50% of the instruction space.

It's not wasted when it makes programs overall smaller, as it does.

It is wasted if its reduction is less than that of alternative uses for that instruction space.

Re: RISC-V: They Should Have Known Better

#217

Post by dmitrygr » Sat, Aug 15, 2026, 5:37 PM UTC

brucehoult wrote: post #151

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.

Performance is subject to debate and quality of implementation and whether such implementations will ever be financed and made ... But *code size* is a demonstrable fact. RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23. Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of va…

> RISC-V has by far the most compact code of any popular 64 bit ISA,

Forgot to say “RISC”. Cause else: amd64

Re: RISC-V: They Should Have Known Better

#218

Post by creato » Sat, Aug 15, 2026, 5:37 PM UTC

dreamcompiler wrote: post #138

spicyjpeg wrote: post #67

Earlier quoted context omitted.

RISC-V is in many aspects just legally-distinct-MIPS, from the base instruction set all the way up to how certain extensions introduce kludges that are very reminiscent of later MIPS additions. While I do somewhat agree on the fact it was a huge missed opportunity to improve upon MIPS's technical flaws in order to realistically compete against the likes of ARMv8, we still have to keep in mind that the primary driving…

> it still is a much better starting point than coming up with your own bespoke ISA 5 years ago I would have agreed with this but now I'm not so sure. We live in an era where you can tell a robot "Here's some C code. Design a 64-bit ISA, write the Verilog to implement it in an FPGA, write a C compiler for it, and use it to compile the C code I showed you earlier." And now your ISA and your compiler are part of your m…

If that's really all it takes, then it is not much of a moat.

Re: RISC-V: They Should Have Known Better

#219

Post by aengelke » Sat, Aug 15, 2026, 5:41 PM UTC

amluto wrote: post #196

wren6991 wrote: post #193

Earlier quoted context omitted.

Yes, I'm serious. I think the overlap is an aesthetic problem rather than a practical one, given that: * The profile used by "Big SoCs" already explicitly depends on F + D + C, implying ZcdZcf, so the newer Zce won't be implemented. * The compressed float load/store opcodes repurposed for Zce are often unimplemented on embedded processors. * The ELF file has an attribute section telling you the exact ISA string. If y…

In x86 land, there are, as a practical matter, four ISAs: real/v8086 mode, 16-bit protected mode, 32-bit protected mode, and 64-bit “long” mode. Machine code targeting one of these will be executed correctly by the CPU as long as the CPU is in the right mode. (Really it’s messier — there are the CS.D, CS.L, and SS.B bits plus the control bits for v8086, protected and long mode, but this barely matters.) Sure, this is…

> But you will not find multiple different CPUs that decode valid instructions differently. If I run your weird old x86 code, either it will run correctly or it will fault.

Oh, that's not completely true. Intel 64 and AMD64 are not identical and they certainly have encodings that behave differently. As an example: f3 41 90 is pause on Intel, but xchg r8d, eax on AMD (granted, this is not a canonical instruction encoding). 66 e9 xx xx yy yy is a unconditional jump to a 32-bit relative offset on Intel, but on AMD, the offset is 16-bit only (yy yy are the start of the next instruction). x86-64 is typically used to refer to the very large common subset, but this doesn't mean the implementations behave identically.

There are also some weird corner cases where CPUs aren't 100% backwards compatible, just backwards compatible enough for the software that matters.

Re: RISC-V: They Should Have Known Better

#220

Post by pavlov » Sat, Aug 15, 2026, 5:42 PM UTC

inigyou wrote: post #68

spicyjpeg wrote: post #67

Earlier quoted context omitted.

RISC-V is in many aspects just legally-distinct-MIPS, from the base instruction set all the way up to how certain extensions introduce kludges that are very reminiscent of later MIPS additions. While I do somewhat agree on the fact it was a huge missed opportunity to improve upon MIPS's technical flaws in order to realistically compete against the likes of ARMv8, we still have to keep in mind that the primary driving…

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

Patents only last 20 years.

If you build your architecture on ideas that are documented to be older than twenty years, it greatly reduces the risk that a patent holder comes from nowhere: even if they did have the patent, it would have expired.