Comment by wren6991
2 days ago
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 a simple implementation.
I think Dmitry's points are largely on-target, though I have filed my usual statutory complaint that every rant that includes a bitfield diagram for the RISC-V J format should accompany it with a similar diagram for the Arm T32 BL encoding.
> RISC-V is .. fine.
Yeah, so was 8051 and it sucked too :-). I appreciated having this rant all in one place. Ranting against bad architecture is always cathartic and absolutely useless since the people who built and now champion the bad architecture are invested so one's rant simply irritates them. And like the parent comment here, I too find RISC-V "useful" in that it has sufficient tooling to make most everything foundational 'out of the box' rather than me having to build it.
Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are, as long as you have cross compilation with the gcc suite and an open source way to program and debug things. Before RISC-V, working on a bespoke ISA and computer architecture was never going to "go" anywhere except perhaps into a paper or conference talk. Now there is evidence of a non-zero chance of it going mainstream. :-)
> Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are
Of course! Most people in the computing world work way higher up the ladder of abstraction. I suspect a small minority of working software engineers know what an ISA even is.
I did some contract work in web development for a time. It is staggering how few people understand how the javascript they write gets executed on the machine. People don't understand pointers, or virtual machines, or in many cases how JS bundlers work, despite using them daily.
In some ways, this is a sign that our abstraction layers have been a great success! People can program for the virtual javascript machine, without needing to understand how the actual machine works, or how it emulates javascript. Is this the future we wanted? I'm not sure. But it's here.
Definitely. I’m a weird software guy that got a hardware degree in college so that I could understand all the low level stuff. I remember there was a joint project with the hardware (ECE) and software (CS) students to build a simple computer with bit slice and microcode and program it to do something (I forget what). I remember the software students being bewildered that there was no division instruction in these systems (because who needs that when you have shifts and add/subtract). Nowadays, with so much stuff running in browsers, the average software engineer has no clue what the hardware is doing.
What's next? Programming Javascript without understanding Javascript??
1 reply →
> Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are
To the extent that Raspberry Pi shipped a microcontroller that can literally be either RISC-V or ARM (indeed, one of each at the same time I think?)
RISC-V, it seems to me, lives in that cognitive space occupied by things like: open source, open weights, C, HTML, ethernet, Greggs sausage rolls and VHS.
Far from optimal, obviously flawed, and could change human society for the better. Ubiquity is inevitable.
What’s far from optimal about open source? Open source seems like a window into another universe, which is just lightly better than ours: people just working on problems and sharing solutions, because humans are basically good social creatures that enjoy solving problems. To the extent to which there are issues like the difficulty of funding open source projects: our society is wrong, not open source.
Not sure why you had to take a pop at Greggs there. Nothing wrong with a hot sausage roll at all. Assuming you can find a hot one.
4 replies →
Nobody wants to cross compile a full linux OS though just for their project. I assume most are using debian multiarch (as they do for arm), and that does mandate a common RISC-V ISA subset. So presumably this will drive further standardization
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).
1 reply →
China is different - the state probably has impact on cpu/mcu vendor selection.
1 reply →
> 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.
18 replies →
Coming up with any ISA and coming up with a good or better ISA are two very different things.
If that's really all it takes, then it is not much of a moat.
4 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.
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.
2 replies →
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...
11 replies →
> Of course not because that's impossible to prove.
Why?
6 replies →
100% agree. Is it ideal? Nah. Can you launch successful products with it with only a moderate amount of headache? Yep!
Heart of our system that powers a household name devices is a RISC-V multi-hart SoC. It does quite a bit - a little bit of compute, a little bit of DSP. Definitely not the best fit, but cheap and works well enough. The buggest gap for us was the lack of the decent debugging featurea like ARM's Data Watchpoint Traces - but maybe there is an extension for that already?
I'm guessing you're using one of RISC-V ESP32 variant (ESP32-C3?)
Nope, that is a custom SoC that had SiFive RISC-V cores from the times when they still did embedded stuff.
> RISC-V is... fine
Exactly.
> It satisfies my two requirements for an ISA as a hobby CPU designer...
You probably have some unstated requirements as well, such as available toolchains and "vetted well enough to actually be able to run code."
Risc-V now occupies the Schelling point for people who, for whatever reason (rent-seeking and security top the list) want to leave the x86 and Arm ecosystems.
Luke is too modest. Something in the region of 5 million chips containing his hobby CPU have shipped since launch on August 8, 2024.
Are we talking about rp2350 ? Because the rp2350 can be config as pure arm soc.
In fact, if we are talking about successfull riscv soc, RISC-V esp32 may have better chance
Could you share a link or more details? What is this hobby CPU project?
6 replies →
They did explicitly specify:
> 1. Supported in mainline LLVM and GCC.
Which pretty well encapsulates the ecosystem requirements.
>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.
You can’t fix the mutually incompatible overlapping encodings in post.
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.
I… you can’t be serious.
16 replies →
Sure can. Just change the encodings.
You thought RISC-V chips were compatible with each other beyond the basics? They're not. RISC-V is only a starting point for designing the ISA your chip will actually implement. Don't get me wrong - it's still beneficial that simple code works on many chips.
HP wrote a JIT to migrate old applications to their new hardware. So did Apple, twice. I don't know if IBM were the first but they've done it a few times as well for their mainframe hardware.
In HP's case, they tried running their JIT to translate from architecture B to architecture B and ended up with better performance than running it directly.
3 replies →
Practically you don't simultaneously want those overlapping encodings.
> diagram for the Arm T32 BL encoding
is that... bit xor?
did they attempt signed immediate, but gave up 3 bits into a 32 bit immediate?
wtf
It originally had a range of 4 MiB, and they extended it to 16 MiB in a later ISA revision. The bits with the XORs were originally constant-1 and they wanted to keep backward compatibility, so bits J1 and J2 are interpreted as "if this bit is clear, toggle this position in the leading sign bits".
There is very cool history as to why. In armv5 the BL was two separate instructions. You could take an interrupt in between. And it was documented what each did. Veeery cool. Then they wanted more range. And now that they redefined the two halves as one instruction that could not be in halves, they also redefined a few bits that were always 1 before, to allow the second half of the instruction to be recognized right without a “previous instruction was first half of BL” flag somewhere that would need to be context switched and all that.