49 ms·
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 i
by wren6991 2mo 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.
- zephen 2mo ago> 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.
- andrewflnr 2mo agoThey did explicitly specify: > 1. Supported in mainline LLVM and GCC. Which pretty well encapsulates the ecosystem requirements.
- brucehoult 2mo agoLuke is too modest. Something in the region of 5 million chips containing his hobby CPU have shipped since launch on August 8, 2024.
- dgellow 2mo agoCould you share a link or more details? What is this hobby CPU project?
- LukeShu 2mo agoLuke Wren works at Raspberry Pi and designed the Hazard3 CPU core that is in the RP2350 chip.
- aurelian15 2mo agoI think the GP is talking about the Hazard3 [1] core. This is one of the CPU cores besides the ARM M33 instantiated on the RP2350 µC [2]. See this article from Luke Wren (Wren6991) back when the RP2350 came out [3]. [1] https://github.com/Wren6991/Hazard3 https://github.com/Wren6991/Hazard3 [2] https://www.raspberrypi.com/products/rp2350/ https://www.raspberrypi.com/products/rp2350/ [3] https://www.raspberrypi.com/news/risc-v-on-raspberry-pi-pico-2/ https://www.raspberrypi.com/news/risc-v-on-raspberry-pi-pico...
- dgellow 2mo agoThank you!
- ACCount37 2mo agoWhat I find interesting is that RP2350 is designed as "one or the other", no way to use ARM and RISC-V concurrently, and has fuses that can kill ARM M33 cores outright. Makes me wonder if an "ARM cores fused off, RISC-V only, no ARM fees" SKU is possible.
- LukeShu 2mo agoSeveral of the peripherals in the RP2350 are also ARM IP.
- brucehoult 2mo agoYou can choose Arm in one pair and RISC-V in the other pair if you want.
- mrheosuper 2mo agoAre 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
- spicyjpeg 2mo agoRISC-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.
- inigyou 2mo agoHas it been proven that no patent troll holds a patent covering RISC-V? Of course not because that's impossible to prove.
- wren6991 2mo agoYou might find this relevant: RISC-V Genealogy (2016) https://riscv.org/wp-content/uploads/2025/02/EECS-2016-6.pdf 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-Instruction-Lineage-Poster-v6.pdf https://riscv.org/wp-content/uploads/2025/02/RISC-V-Instruct...
- phire 2mo agoYeah, 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.
- amluto 2mo agoYou can’t fix the mutually incompatible overlapping encodings in post.
- monocasa 2mo agoPractically you don't simultaneously want those overlapping encodings.
- wren6991 2mo agoThey 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.
- adastra22 2mo agoI… you can’t be serious.
- wren6991 2mo agoYes, 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 you're debugging an embedded system you probably depend on the ELF file anyway for DWARF info as you likely don't have frame pointers. If you disagree then that's ok, I'm happy to be disagreed with, but please explain.
- amluto 2mo agoIn 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 messy. But, critically, on x86, these are all modes, and any CPU that supports them makes them detectable and supports them in the same way. If you run long mode code outside long mode, some opcodes will be interpreted as the wrong instruction. 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, and all these modes are older than RISC-V. To the extent that there are lessons to be learned, RISC-V should have learned them. The fact that you can apparently find two RISC-V CPUs that decode some ordinary user mode instructions based on published standards as entirely different operations is bizarre, to say the least. The fact that the relevant CPU features can’t even be enumerated in user mode just makes it worse. (There are edge cases in x86. Some invalid opcodes have different lengths on different vendors’ CPUs. This is not a problem in practice because, one way or another, they fault. There was also a little glitch in the 64-bit design where some really really old x87 FPU code that uses exceptions cannot be corrected handled by a kernel on a modern CPU.)
- jacksons5f 2mo ago100% 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?
- minetest2048 2mo agoI'm guessing you're using one of RISC-V ESP32 variant (ESP32-C3?)
- jacksons5f 2mo agoNope, that is a custom SoC that had SiFive RISC-V cores from the times when they still did embedded stuff.
- coldtea 2mo ago>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...
- wren6991 2mo agoThis is a good point, and of course this is why IP lawyers are so important: they protect you from other IP lawyers.
- ChuckMcM 2mo ago> 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. :-)
- dofm 2mo ago> 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.
- pertymcpert 2mo agoNot 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.
- riversflow 2mo agoyou should review the data on processed meat. It's one of the least healthy things you can eat.
- benj111 2mo ago
- NooneAtAll3 2mo ago> 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
- wren6991 2mo agoIt 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".
- dmitrygr 2mo agoThere 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.