Has it been proven that no patent troll holds a patent covering RISC-V?

Of course not because that's impossible to prove.

> 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 moat. I can just see the VCs salivating.

I'm guessing you're using one of RISC-V ESP32 variant (ESP32-C3?)

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.

Practically you don't simultaneously want those overlapping encodings.

They did explicitly specify:

> 1. Supported in mainline LLVM and GCC.

Which pretty well encapsulates the ecosystem requirements.

Luke is too modest. Something in the region of 5 million chips containing his hobby CPU have shipped since launch on August 8, 2024.

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.

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.

> […] then the CPU vendors can optimize on one side […]

I find the statement ironic and somewhat amusing (or bemusing – depending on the perspective) for reasons entirely unrelated to CPU's and/or RISC-V.

I keep hearing the phrase «we shall leave that to the vendors» every now and then. Only a few days ago, whilst attending a working-group session on an emerging data exchange standard, precisely the very much same argument was bluntly stated: «We do not particularly care how complex the specification becomes because the vendors will implement it. We shall leave it to them».

The issue is that «the vendors» are not a single mythical intelligence or force possessed of infinite technical wisdom, unlimited, cosmic scale engineering resources and an relentless desire to right the wrongs.

They are businesses. They have narrow commercial objectives, conflicting priorities, disparities in the engineering talent and resourcing and, quite properly, incentives to advance their own products – you are right, to compete with other vendors. Where an opportunity appears to increase market share, lock customers in, differentiate their platforms and products or shift implementation burden elsewhere, one should expect them to notice it. It is not an accusation, it is merely an acknowledgement that vendors tend to behave like vendors.

So with «the vendors will do X», at best, we may hope that vendors will deliver an interpretation of the specification – to a degree, provided that doing so aligns sufficiently well with their commercial interests. An equally plausible outcome is that they will not – or that they will each implement mutually incompatible interpretations whilst proclaiming full compliance.

> 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 simpler than RISC-V instruction form decoding.

I know there's an earlier criticism of RISC-V that points out that one of the common instruction sequences for which "macro-op fusion" is the suggested solution involves 5 instructions... and I don't think any of the existing chips ever fuse more than 3 instructions?

> 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.

I don't think that's actually true. There's weird historical baggage and whatnot. But if you're running in long mode, it's actually a fairly sensible architecture with useful memory addressing modes.

There is a general pattern I've noticed, where people from past generations fail to share the lessons they have learned somewhere that is accessible for the next generations, so they are stuck repeating the lesson.

In particular, the next generation might recognize some aspects that seem bad and be confused over how to prioritize correctly because they don't know any better.

2^N I think, but who's counting.

x86 chips don't truly exist anymore. They only use it as a compressed ISA for a more capable internal representation that can be freely updated at any time.

You don't really have to have a separate decoder every 16-bits. What you have is a length decoder every 16 bits (so just a single nand gate over the first two bits versus a huge chunk of the prefix/opcode part of the decoder for x86), which then feeds into a set of muxes for the actual decoders. The actual increase in complexity ends up coming from the critical path of the stack up of length selection affecting start addresses (and therefore mux selections) for later instructions in the block, but even that's not nearly as bad as it sounds because you can use the same base trick behind a carry lookahead adder. When I did some experiments a while back, it ended up being less than half a pipeline stage overhead versus fixed width instructions kind of across the board.

So not nothing, but very far from a deal breaker even for wide 8, 10, or even 12 wide cores.

Nobody in high-performance does fixed-width instructions that allow lineary scaling parallel decoders. Arm basically requires certain instructions to be cracked into multiple uops before rename. That ends up analougus to decoding compressed instructions. RVC increases complexity before decode, how much that impacts things idk.

I don't believe this will impact performance in practice, because nothing forces CPU vendors to implement fast compressed instructions. If compressed instructions become slower than non compressed instructions as the instruction decoders get wider, compilers will stop emitting them in the future.

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.

The future set of people who once would have "work(ed) for free to design you a state-of-the-art kernel"? If the tail is long enough passionate hobbyists will do it because they love it...eventually.

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

Considering just how many of the problems seem to come from RISC-V being a clean-sheet design, I suspect we would be better off not doing another.

What I am interested in is the idea doing an AArch64 style revamp of the ISA, were much of the non-encoding semantic stuff is kept, but the entire instruction encoding (plus all the CSRs, and other things) are reworked to be sane.

You might even do two reworkings in parallel, with one variable-width encoding optimised for microcontrollers, thumb-style; And the other being a fixed-width encoding optimised for wide out-of-order cores.

And at the same time, you make a bunch of extensions mandatory, and unify others into bigger chunks; Code compiled to one of these two encodings would know it had access to a much wider range of instructions.

The idea would be that any C code targeting RISC-V can be compiled to this encoding with close to zero changes, and that mechanical translation of exiting RISC-V binary code should be "possible", as none of the underlying semantics have changed. And the same would help any core wanting to natively support both (or all three) encodings, you would only need a front-end translator.

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.

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.

I'm not sure this is a real problem - for embedded you know a priori - for arbitrary desktop/SBC machines, misa will be available in kernel mode and /proc/cpuinfo will be available in user mode.

You don't need to probe what hardware you're running on because you know being the manufacturer. The code is bespoke for your solution and nothing more. No foreign code is going to run on it.

Different problems require different solutions. An electric blanket doesn't need a barrel shifter for multiplication or even floating point hardware. The ISA can change depending on what's needed to solve a particular problem, not to provide an "one size fits all" solution.

It's used widely in Chinese stuff (which is basically everything) so in terms of volume it's probably already dominant.

In terms of dollar volume ARM is still the leader, especially for higher-end (application level MCUs) stuff. RISC-V MCUs with MMUs or MPUs are scarce at the moment.

Risc-v is nowhere near dominant, people are just being swayed by headlines such as Western Digital or Nvidia shipping billions of risc-v cores.

I do find it odd that you go on and compare to x86 marketshare however, the topic you've quoted is very clearly about MCU and whilst 8086 MCU still exists they haven't been used in greenfield projects for decades. Let alone any more recent x86 implementation.

Noone uses an 8051 because it's elegant. Billions are still still sold every year because no matter if you learned it in the 70s or last week and no matter who made it, the basics are exactly alike. Software matters; ISAs don't.

I believe the market will standardize on certain extensions for specific solutions. No one is going to make a mobile phone with only RV32I, for example.

> Because nobody will write software for 300 unique hardware variations

Who said they have to? One can select a RISC-V configuration for a baseline for a particular purpose. Desktop? Choose the one that's most powerful.

ARM is more popular than x86 and is less consistent than it.

And Arm dropped a T16-like encoding entirely from their 64 bit instruction set.

If they did everything exactly the same they would be the same ISA not different ISAs.

It's just as easy to point to things that RVC can do that T16 can't.

You need to look at a far larger picture to decide on who made the better decisions overall.

Honestly, I would feel uncomfortable if I were designing an instruction encoding and came up with some addressing mode format where there are two bits for a displacement. I would pull myself aside and have a word with myself. That's just me, though.

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.

As I’ve come to understand it, standards simplify intensionally, not extensionally. For those who select a part that is compliant with a standard, more standards to choose from is better because engineers are able to make better tradeoffs; they’re not forced to select a part that does way more than the application needs thus making the product more expensive if there are lots of “competing” standards: some do less some do more.

For RV, a litany of standardized modules creates a system where each capability that the module provides will have a standard interface. No manufacturer is forced to invent extensions bespoke to their implementation, but they’re not forced to support everything the most powerful models do either.

Just my two cents.

6809 is a better exemplar, but, yeah, we knew this stuff way back when.

The problem is that everybody around RISC-V wants to sell IP instead of a chip. Most of the worst brain damage follows from that.

The rest of the brain damage follows from "We want to compete with ARM A-Series cores." No. Just ... no. Nobody willing to spend that much on a processor gives one iota of damn about ARM licensing fees.

So, the semiconductor market wants a cheap, consistent chip that operates in the deep embedded space while the RISC-V ecosystem considers the mere thought of that to be icky beyond reason. And China will push on this like Longsoon and pray that somebody figures out how to make it not suck (Prediction: they won't succeed.)

And, the worst part is that RISC-V has basically lost its window. The single possible advantage that RISC-V had was that as people converged to a shared tooling ecosystem it would create lockout. Unfortunately, that convergence never happened so, at best, we got some shared compilers. And, now, AIs can basically one shot all your other tools around it and probably the compiler not far behind. And there goes your ecosystem lockout.

It's not. In practice you have two scenarios:

1. You have a microcontroller. You're compiling code yourself and the docs tells you what features are available and which compiler flags to use.

2. You are writing application code. In that case you simply target RVA23.

The edge case is the same edge case where you use CPUID on x86, I.e. you want to target say RVA23 and RVA28 in the same binary. In that case you do have to use the OS APIs to discover what is supported... which is slightly annoying, but in practice you're just calling a different function.

In theory `mconfigptr` will eventually make this a lot nicer but nobody has put in the effort to define how it works yet (last I heard they were looking at ASN.1 sick emoji).

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 in a register. This is your most basic function call instruction. It only has an immediate range of 21 bits. Even a few bits scavenged from somewhere would really help it, ±megabyte of range is in the vicinity of what you need for internal calls but not generally enough.

It's a 32-bit instruction, so why can it only support 21 bits of immediate? Because the people who made RISC-V decided that implicit register arguments are works of the devil, and that you need to use any register as argument for any instruction. Therefore the RISC-V JAL instruction contains a 6-bit field for destination register, which is where they store the next instruction address. Never mind that there is not and will never be a compiler that emits anything but the ABI compliant return address register "ra" to that field, we decided we won't have implicit arguments so by god we are going to pointlessly sacrifice 5 bits⁰ of space in every single fucking branch, often forcing the user to construct the address in a register and use more instructions instead, which is much worse than it sounds, because branch prediction is easier for immediate branches.

This is not the biggest actual problem with the architecture. They added an instruction that adds upper immediate bits to PC, which the any core that implements instruction fusion fuses with jalr. But that sacrifices the low-end, that doesn't fuse anything, and uses two instructions for an extremely common pattern that everyone else manages in one. The reason I hate this one so much because there is no actual reason to make this mistake. A five minute conversation between two engineers should have killed this one in the crib, literally everyone knows not to do this. Apparently other than the RISC-V folks.

0: I give them one bit, because the opcode is short and they use the zero register to suppress the link and turn it into a normal jump.

I mean, a shuttle run is pretty cheap these days. If you have silicon, and customers, scaling past a shuttle run that worked is pretty low additional cost.

Anther ISA like ARM? It seems pretty palatable to just about everyone not academic.

  > fired half of them