There are lots of somewhat successful yet little-known Chinese companies with their own proprietary architectures and the toolchains to match, so I don't think it's that clear-cut. (That said, most if not all of them are somewhat MIPS/RISC-V-ish anyway...)
I do think 8051 is better when you don't need 32 or even 16 bits. Even 4-bit MCUs are still around in ultra-low-cost ultra-high-volume products, which is to say RISC-V is, as you said, just a different flavour of MIPS with very similar tradeoffs.
Interestingly Synopsys's ARC's latest version ARC-V is RISC-V.
I think all major FPGA vendors now offer fully supported RISC-V soft cores either alongside their older proprietary ISAs or as the latest upgrade. Several (e.g. Microchip and Gowin) have included real RISC-V cores inside FPGAs.
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.
There are thousands of people who could design such an ISA in a couple of weeks, without any AI assistance.
The hard part, which has always been the moat of RISC-V, is writing all the required support software for a new ISA, i.e. all the utilities from binutils (assembler, static linker, ELF/DWARF utilities), compiler backends at least for gcc and llvm, debugger (at least a port for gdb server), dynamic linker and standard C library, possibly some parts of the standard libraries for other programming languages.
Previously this could have taken years and it is the only reason that has always justified the choice of RISC-V for minimum cost, despite how bad the ISA is.
If today the porting of all these software support applications to a new ISA could be accelerated with AI assistance from a couple of years to a couple of months, that would certainly enable the design and use of custom ISAs, and RISC-V would lose its appeal.
Let me know when you've got it all worked out and published. Should be easy, right?
That's why it's so bizarre that the RISC-V design is so awful.
The hard part is the software support side (though, as comments elsewhere in the thread point out, AI is pretty helpful there) and then those lovely pieces like specifying the precise behavior of interrupts.
If it had a snowball's chance in hell of going in to any kind of production anywhere, I'd have no problem spending the next month laying out an ISA. But, again, as this thread makes very, very clear: ISA really just doesn't matter.
With that said, RISC-V is a nice baseline for designing another architecture. Start with RISC-V, and go from there.
No links? You may have dreamt about it instead.
The only argument I've ever seen for RISC-V that's vaguely logical is that there's no licensing to Arm involved, but since I can get M0/M3 devices for a dollar or so with infinite tool and library support that's something that's totally irrelevant for most users. And if I don't mind going with Chinese suppliers there's no licensing to Arm being paid anyway.
Apart from being able to thumb your nose at Arm, I just can't see what the point of RISC-V is. Is that really all there is going for it?
How expensive is it to license the instruction set so you can expand it?
And how would you get this all into Clang? Nobody wants to use your custom compiler. It's certainly not going to be as fast as Clang!
Of course not because that's impossible to prove.
The RISC/MIPS concepts date back over 40 years. The base instruction set is intentionally designed with unencumbered, expired, or public-domain architectural concepts.
RICV-V microarchitectures and implementations are at much high risk of violating patents. Especially anything that is even slightly high performance. SiFive, Andes , and Alibaba’s T-Head are filing thousands of patents on microarchitectural optimizations and extensions. China's RISC-V patent-sharing alliances and other industry groups are building defensive patent cross-license around their RISC-V-related patents.
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.
One reason that RISC-V has so many optional extensions is that you can trust the core is very likely to be patent-free (because everything in it is documented to be older than 20 years) and just evaluate the extensions you need.
Or in poster form: https://riscv.org/wp-content/uploads/2025/02/RISC-V-Instruct...
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.
It's worst aspect maybe.
I don’t know enough about high performance microarchitecture design to evaluate that argument confidently, but it seems to make sense to me.
By the time you have an out-of-order core, there is already so much shared state you have to synchronise, and you have a bunch of complex mechanisms for dealing with it. Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it.
And we already have the solution, it's register renaming. We are already renaming all the GPRs and FPRs, and we are probably also renaming part of fscr (because turns out, RISC-V does have flags for floating point operations), maybe a few other bits of state. So we just use the existing renaming mechanism to rename a bank of flags registers; That single logical shared flags register is actually backed with a bank of non-shared physical flags registers, neatly solving all concerns.
Sure, the renamed flags do take up a bit of die space. But IMO they don't add any extra design complexity, and shouldn't have any performance impact on maximum clock speed.
RISC-V isn't quite as disadvantaged by the lack of flags as some might suggest (and I wouldn’t say the lack of flags is RISC-V’s worst aspect), but there are a few sequences (add-with-carry, some conditional-moves, detecting overflow) where RISC-V is forced to burn an extra instruction or two to deal with the lack of flags, and IMO eliminating that would be worth the cost of slightly more die space.
Also, avoiding the need for dedicated compare-and-branch instructions would free up encoding space for other things (including larger range on branches)
I agree in general, we do however see that the cost of flags isn't free by the fact that most modern Arm processors only support ADCS on half of the ALUs supporting ADD. If it was free/negligible, you would see ADCS support on all ALUs.
The lack of flags on those ALUs probably tells us more about the lengths CPU designers will go for reasonably small savings than it tells us about how much flags actually costs. And it's probably more of a "our metrics never gave us enough justification to even consider adding flags to the extra three ALUs" than "we considered it, but the cost was too high".
By the time you have an out-of-order core
Doing the deliberate choice of leaving flags out of the core and then using them in the fp ops ext will nudge designers towards "this is probably the point you should think about out-of-order execution"
When you read their stuff, they're constantly overestimating the value of ultra-minimalist CPU designs in the modern context. In fact, they often show little understanding of the real impact of ISA design decisions on implementation complexity, so some of their decisions don't even make sense as minimalist decisions.
To expand on the low value of minimalism: even in trailing edge process nodes, if you're designing something on the scale of a simple single-issue in-order 32-bit RISC core targeting no particular frequency, gates are essentially free. The RISC-V guys are badly out of touch. If minimum gate count mattered as much as they think it does, there would still be a thriving market for 8-bit microcontrollers. Instead, they're steadily losing market share to 32-bitters, even in applications where an 8-bit µC would be more than enough. It's not the 1980s, you don't have to struggle to fit a featureful 32-bit core into a single die anymore, but they're hellbent on relitigating that era's debates.
But the argument in the spec explicitly uses the "added complexity to out-of-order microarchitectures" as a part of the justification for not having conditional move (and flags). It's the most commonly parroted part of the argument (see above) and the part of the argument I'm responding to.
I actually agree with much of the spec's argument. The cost of not having flags is pretty low, the MIPS approach does work pretty well, and it does simply things.
I'm just not sure it was the right trade off, and I strongly disagree with its attempt to use OoO cores as part of the justification.
I regard it as a mistake of RISC-V. The flag register was invented for good reasons, and dropping it is a trade-off I personally do not think is worth the downside.
Why?
The set of US patents, however, are not infinite and, IIRC, is also public. That said, IP laws are a mess.
That being said, I don't expect someone filing a new patent after a RISC-V extension being published to last much longer beyond discovery in most cases, which should keep costs in lower end. Specially so in cases of bad faith.