Comment by spicyjpeg

2 days ago

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 force behind RISC-V is and has always been fixing the legal flaws instead.

There is indeed plenty of value to be had from a standardized (if poorly) PlayStation-1-era instruction set you can safely implement in silicon with no risk of a zombie company husk coming after you, especially in the ASIC space where (as Dmitry himself recognized) anything is better than an 8051 core you need a copy of Keil C51 and a lot of patience to write code for. Even if you end up having to add custom extensions, it still is a much better starting point than coming up with your own bespoke ISA, building a toolchain around it and convincing potential customers that your proprietary architecture is worth the effort to deal with over another vendor's licensed Cortex-M cores with full GCC and LLVM support.

it still is a much better starting point than coming up with your own bespoke ISA, building a toolchain around it and convincing potential customers that your proprietary architecture is worth the effort to deal

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.

  • Google search turns up LoongArch (RISC), Shenwei (CUDA-like, HPC), UniCore (RISC). ESP32 is using Tensilica LX6/LX7 RISC base (RISC designed for custom hardware extensions).

    • C-Sky and Andes NDS32 were popular enough to be supported by both GCC and the Linux kernel, both switched to RISC-V. ESP32 switched to RISC_V for all new chips.

      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.

  • China is different - the state probably has impact on cpu/mcu vendor selection.

    • All states regulate, subsidize, or otherwise exert influence on companies acting in their territories. China is not unique or different in that regard. They have been forced to try somewhat harder, but that was really due to the actions of the US trying to restrict their access to free trade. Chine restrictions on buying western tech didn't come until far after NATO countries had placed similar restrictions on Chinese tech.

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

  • Designing a good 64-bit ISA, much better than RISC-V, is easy.

    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.

    • > Designing a good 64-bit ISA [...] is easy [...] could design such an ISA in a couple of weeks

      Let me know when you've got it all worked out and published. Should be easy, right?

      8 replies →

    • The effort to support architectures is now minimal with AI assistance. I made a hobby architecture (based on Intel, but with some changes; I was making an "alternate history" as if a few decisions in the past had been different) and it was pretty much trivial to spit out support not just in gcc and llvm, but I also, for fun, made WATCOM backends and a few other things.

      With that said, RISC-V is a nice baseline for designing another architecture. Start with RISC-V, and go from there.

      4 replies →

    • That's why I've never understood the point of RISC-V. Anyone can design a (reasonably OK) ISA. It's everything else that's the hard part. It's like announcing a new house, it's going to be pained Benjamin Moore Yellow Oxide and everything else is someone else's problem to sort out. Success! We've got a new house!

      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?

      3 replies →

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

    • In the set of all possible working implementations, there are one or more that are novel enough to become a moat legally or otherwise. If everyone has the same power (number of tokens) then capability (experience and understanding) becomes the differentiator to “find” that moat first.

      3 replies →

  • How is that a moat, if anyone else can do the same thing?

    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!

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

Of course not because that's impossible to prove.

  • If you iterate trough every concept RISC-V has, you might be able to prove it.

    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.

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

      10 replies →

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

    • How quickly does the industry move? Would there be any value in a 2006-era instruction set? How would you even start making sure you didn’t infringe on any patents that came after 2006?

      1 reply →