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 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.
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.
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.
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.
"it's impossible to prove a negative" is a simplification. A negation is just the oppositive of an affirmation. If the affirmation is "there is an element E of an infinite set S that satisfies property P", the negation would be "there is no E in S that satisfy P", which would make proving by enumeration require checking every element of an infinite set, which is impossible. But other forms of proof might be possible.
The set of US patents, however, are not infinite and, IIRC, is also public. That said, IP laws are a mess.
Someone might also file a new parent, then apply it against RISC-V. You'd think that wouldn't be allowed to happen, and maybe it isn't, but only an expensive lawsuit will prove it
Given the nature of the US legal system as based on common law, that applies beyond patents, and may affect ARM and x86 as well. In the end, the real, effective law is the one understood by judges, adjucated in court cases, built on precedents.
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.
> 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.
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?
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.
Yes, 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.
In 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.)
> 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, that's not completely true. Intel 64 and AMD64 are not identical and they certainly have encodings that behave differently. As an example: f3 41 90 is pause on Intel, but xchg r8d, eax on AMD (granted, this is not a canonical instruction encoding). 66 e9 xx xx yy yy is a unconditional jump to a 32-bit relative offset on Intel, but on AMD, the offset is 16-bit only (yy yy are the start of the next instruction). x86-64 is typically used to refer to the very large common subset, but this doesn't mean the implementations behave identically.
There are also some weird corner cases where CPUs aren't 100% backwards compatible, just backwards compatible enough for the software that matters.
> The fact that the relevant CPU features can’t even be enumerated in user mode just makes it worse.
User-mode feature detection is usually used to select paths for acceleration instructions, like SIMD or crypto. The overlapping RISC-V instructions don't fit in that category: they're compressed versions of basic functions, mostly used in epilogs/prologs, which would be unconditionally compiled in.
There are no overlapping encodings in the 32-bit encoding space and I'm really hoping it stays that way.
> To the extent that there are lessons to be learned, RISC-V should have learned them.
Yeah, I think I agree with this. Also I wish I had been there when Andrew Waterman was writing his master's thesis so I could ask him not to include Whetstone in his size benchmarks, so that we might have left that encoding space free and avoided this conversation :-)
> 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.
If RISC-V was good enough for AMD to use it in their controller for their GPUs and it became cheaper than ARM, and NVIDIA is using it in many places, it was better to build upon than getting a change in ARM/x86 licensed and approved by Jim Keller, it's good enough.
It turns out that the cost of waiting years for an ISA change is more costly than fixing whatever problems it has.
Having written a few RISC-V cores, worked on a chip design project that used RISC-V cores, and generally being OK with the architecture in real-world use cases:
What the heck is this guy's problem? Just about every thing he mentioned as a problem is not a problem in practice. Too many options? Who cares, you're not trying to write code that runs on every possible configuration. Either you're writing embedded firmware and know exactly what core you're using, or you're writing an application that runs in an operating system and that system has a minimum ABI like RVA20 or whatever.
Array accesses take an extra instruction? Either you're in a tight loop walking a tiny array and you don't do the full offset calculation per step, or you're walking over an array in RAM and you're bottlenecked by the memory bus.
Hell, 90% of his arguments are "You can't detect X at runtime from user code without relying on some extension" - Yes, that is totally fine. Either you know your target CPU, or you don't - and then you ask your OS for details. This is not some dealbreaker.
From the article - "For example, if you are writing a kernel and want it to support all RISC-V cores" - NOBODY IS DOING THAT. You target a platform spec, not the combinatorial explosion of everything from RV32E to RVA22 or whatever the latest is.
You want to distinguish S mode from M mode? WHY DO YOU NOT ALREADY KNOW THIS?
Instruction encoding is weird? WHO CARES, the decoding is like eight lines of Verilog.
"Who can predict how their binary will act when a floating point store silently becomes a double-register move or a jump instruction, or vice-versa?" - THIS DOES NOT HAPPEN IN PRACTICE.
Guhhhhh, I don't get it. This guy has some vendetta and either has not shipped any risc-v code or is just in love with his own personal favorite instruction set.
It has an effect only in terms of how big an offset you can encode in a relative jump, the _arrangement_ of those bits in the instruction is irrelevant (and already abstracted away in the compiler/linker framework).
Yeah the OP post read to me like someone throwing the baby out with three drops of bath water. If this was presented more like “minor gripes with risc V” I’m guessing I wouldn’t feel that way
My disagreement with the article is mostly the following:
RISC-V is not an ISA, but an ISA generation framework.
If RISC-V would've standardized aarch64 1-to-1, the end result would've still been a huge extension mess, because a lot of people (RVI member) have different requirements and a very happy to build their own subsets, which would then be upstreamed because multiple vendors want the same subsets and compatibility between them. Obviously it would've been better, similar to if RISC-V spawned with RVA23 done, but development takes time and RISC-V International started, because people where already using RISC-V.
RISC-V also is the most DOSed ISA, with people proposing crazy stuff. Just the other day somebody proposed an instruction that would do up to 2^30 16-bit comparisons in one instruction at the largest VLEN. Because they wanted to improve their string processing usecase.
---
In my experience RVA23 matches aarch64 and x86 in uop count (without fusion), code density is better, instruction count is slightly higher. The biggest impact on the instruction count advantage of aarch64 over RVA23 is a single instruction, load-pair, which gets cracked at decode in every high-performance implementation, because it writes to to registers.
The Arm approach to code density is using multiple writeback instructions that have to be cracked and the RISC-V one is RVC. Both prohibit simple linear scaling of parallel decoding, so code density seems to have mattered to Arm enough to make the tradeoff worth it.
the significance and allure of risc-v, the reason china is investing heavily in it right now, has little to do with the technical details of how it works under the hood, it's the fact that it is an open standard not encumbered by intellectual property law. even if it isn't technically the best general-purpose processor architecture, it sets an important precedent by proving that it is possible to develop an open public architecture that the world can use to build computing devices without being extorted by a multinational corporation charging licensing fees or a geopolitical superpower enacting tariffs and sanctions.
It's not just China that has an interest. Multinational corporations also hate being charged licensing fees (see Qualcomm vs. ARM). Here's a list of RISC-V members: https://riscv.org/members/
> it's the fact that it is an open standard not encumbered by intellectual property law.
There are actually many of those. But Risc-V has become, through effective marketing, the Schelling point for anybody who wants to avoid the x86 and Arm ecosystems, both for the rent-seeking behaviors you mention, and also, in some instances, for security reasons.
And, as others have mentioned, the ISA doesn't really matter. As long as it's agreed upon, then the CPU vendors can optimize on one side, and the compiler writers on the other side.
Sure, Risc-V has its warts, but you can certainly say the same about all the rest.
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.
The RISC-V fusion arguments from back in ~2018 didn't really pan out. A lot of those fusion opportunities are just instructions now. slli + add? Zba (sh*add). slli + srli? Zbb (zext.*). slli + srai? Believe it or not, also Zbb (sext.*).
Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are:
* Taking up valuable compressed instruction space; each compressed codepoint has an opportunity cost of 64k uncompressed ones.
* Limited in which registers they can use (usually x8..x15).
* Often clobber their input operand instead of giving a free move.
Also consider that the frequency data that drove the RVC compression decisions was driven by the lack of architecturally fused instructions like sh*add, so any arguments you derive from that data are circular. An instruction can be a good uarch fusion target because it's compressed, and a good compression target because you didn't fuse it in the architecture.
I think designing for uarch fusion in your ISA is coming at it from the wrong end. Fusion is something uarch designers do to make up for shortcomings in the ISA.
Sorry, haven't been following along, but sounds to me that the argument was a valid one seeing how it made the designers add new instructions.
Not sure if there's an impact caused by the late addition as opposed to always having them, but considering this is a fairly core thing what a program does, not sure what degree of fragmentation this causes on the level of compilers and hardware.
x86 effectively killed innovation in the SIMD space by making instruction set support so fragmented, that people had to target the decade-old lowest denominator.
Performance is subject to debate and quality of implementation and whether such implementations will ever be financed and made ...
But *code size* is a demonstrable fact.
RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23.
Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of various binaries, individually or in aggregate.
In 32 bit ARMv7-M / ARMv7-A had a small code size lead over RV32IMAC, but this is reversed in modern RISC-V e.g. if you look at RISC-V Hazard3 vs Arm Cortex-M33 in the RP2350 (Raspberry Pi Pico 2) where you can trivially change one option setting in your project and recompile and test.
The only exception is that the M33 has a single-precision FPU, which neither the Hazard3 nor the Cortex-M0+ in the RP2040 have.
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.
What you find may or may not match reality. In this instance, I don't believe it does.
> We do not particularly care how complex the specification becomes because the vendors will implement it. We shall leave it to them.
This, of course, is a silly argument. Yet, it is completely orthogonal to the one I was making, and is 180 degrees away from the complaints leveled at Risc-V which are that it is an overly simplistic, nay childish, specification, written in crayon by kindergartners.
> 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.
I find this statement accurate, yet condescending. Who the fuck thinks that they are? Claiming that this is an "issue" with my statement appears to be a reductive argument that I have not thought it through. To be blunt, this statement reveals a hell of a lot more about your ignorance on this issue than mine.
> It is not an accusation, it is merely an acknowledgement that vendors tend to behave like vendors.
And yet, we have seen this play out in x86, with Intel v. AMD, and it worked exceptionally well.
> An equally plausible outcome is that they will not – or that they will each implement mutually incompatible interpretations whilst proclaiming full compliance.
Of course, AMD and Intel were always trying to one-up each other, but that is tempered by the necessity for their improvements to be supported by compilers. By the time an improvement is well-supported, the other side has caught up.
With Risc-V this is even more likely to be the case, because proprietary extensions will simply not be that well supported by major compiler vendors, who have a hard enough time keeping up with the ratified ones.
I wrote an RV64IMA emulator recently. I just needed a virtual CPU core that could boot linux, and RV64IMA seemed like the simplest way to do that - and I think that's more or less true.
But then I wanted to be compatible with off-the-shelf toolchains and binaries, and I found myself needing to extend the ISA profile to RV64GC. Not a huge lift, but it involved pulling in a softfloat library. That got me as far as booting Alpine linux.
And then I wanted to be able to boot Ubuntu, which needed RVA23, which was comparatively a much bigger lift, involving the vector instruction set among many other things. At this point I think I'd have been better off just emulating aarch64.
I think I get it. I've tried microblaze-v for a while now. And just look at their interrupt handler. https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/sta... . With the FPU enabled at compile time, that's > 128 memory ops per interrupt. That's insane, especially without an NVIC and chaining and all that. My latency was astronomical, and my maximum interrupt frequency was pitiful. Ended up doing the work (sw and hardware options) to get it to operate more like arm-m, but arm-m doesn't need that work to be done. NVIC is always NVIC, and NVIC is good
Yeah, this is a bug. They should only be saving the FP state if it's dirty.
Also this is one of the reasons I think Zfinx is a better option for embedded (i.e., the standard FP instructions operate on x registers instead of f registers): 31 registers is plenty to hold a mixture of integer and floating-point values, and you avoid the worst-case context save penalty.
Started reading, however I wanted to add this in: a lot of people expect RISC-V to do too many things, and nearly all of those things are "beat every other architecture out there in every way/shape/form, while also being open".
The reality? The fastest "available" RISC-V CPUs don't match the best chips in terms of speed, power consumption, or die area. "available" obviously means the chips that have been released to the public and can be independently benchmarked.
I do think that is okay, however I also think that those involved with RISC-V aren't helping much, and current attempts at standardizing seem to be just creating a bigger problem.
That being said, RISC-V does seem to perform well in specific niches.
The conclusion is honest, and you can of course brute force any ISA into any role. I used to loathe x86 for that reason, but now that I'm older I respect the game.
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.
It just blows my mind sometimes when designers don't learn insanely obvious lessons from the past, basic stuff like "complexity is evil" and "make the fast path overlap with the most common use cases" and "a standard with N optional extensions is actually N! (N factorial) standards."
That being said all real world architectures seem to have messy corners and warts. RISC-V was a chance to do away with a lot of that and they... didn't?
> 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?
You've also got tons of prefixes with opcode dependent rules on what's allowed there, the opcode field itself is variable length (I've seen up to four bytes), you've got instructions that treat that immediate field as additional opcode bytes, etc.
The opcode is 5 maps (8, actually, but only 5 are occupied) of 10-bit opcodes, with the presence or absence of 66/F2/F3 prefixes providing 2 of those bits. If you ignore how the manual describes prefixes and look at it like that (which is suggested by the VEX encoding process), the decoding process becomes a lot simpler. In fact, with one singular exception, this is sufficient information to index into a map to figure out how long the immediate field is and whether or not ModR/M is present.
> 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.
I think MIPS is a great example, and even there I don't think there's the bizarre bifurcation of ISA options RISC-V brings to the table.
As a fellow olderster, I can't help but think that after almost 50 years of "ISA X is sooooo much better than x86 it's obvious ISA X is the future and x86 will be dead Real Soon Now (for whatever todays version of x86 is)" I can only shake my head ruefully and say "ping me when that happens".
Controversial Take (that history proves isn't): Software matters; ISAs don't.
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.
There's still repercussions to the unaligned variable length instruction set that is x86 though, and the decoder and prefetch have to deal with the insanity that falls out from it... ultimately limiting how parallel the instruction decode and dispatch can be.
I keep seeing this line of reasoning and have no idea why it's relevant. You don't program that 'internal representation'. The software people want to run only care if that software doesn't run. Cyrix, Transmeta,NexGen, Centaur, WinChip, etc., etc, theoretically had "more capable internal representation". The only thing that actually matters is "does it run the exact same x86 software I bought X many years ago" and "does it run it at a decent price/performance ratio". Everything else is dick measuring.
Today, we have Intel and AMD, and some bit-player embedded folks.
This is a load of bullshit that largely exists as copium to explain how x86 did the impossible and made a superscalar CISC processor. x86 is doing the same thing that (to my knowledge) all high-end processors do, yet no one tries to call out those chips as compiling to a different internal ISA. But you also don't see any chips trying to run with multiple ISA modes: the closest you get is 32-bit and 64-bit modes coexisting, or ARM's Thumb instruction set.
I haven't kept up with POWER after POWER9, but I recall it to be a true hardwired control RISC, pure as the driven snow. This had some interesting properties (along with other clever designs like eFuses and pNOR) for creating a really credible security posture. They do have a millicode system and chicken bits for oops moments (which are kind of an opposite risk, if you don't get those right for unexpected problems).
Amen. I remember the about 6 months when the benchmark cawboys were screaming that they had to be able to have access to directly program the Pentium Pro micro-instructions because 'that would be so much faster' and no matter how much the Intel architects who actually knew how things worked said "I don't think those words mean what you think they mean" there was some conspiracy to keep the PPro from achieving it's max performance...as if Intel didn't want the PPro to show it's max performance.
Whenever I see someone say this I'm thinking the following:
If what they say is true, then x86 won because ISA doesn't matter, precisely because ISA is the public instruction set architecture. If you can convert anything to a better representation then the argument of exposing the better representation doesn't actually follow.
Additionally, you are claiming that an internal implementation detail that only Intel and AMD know about is secretly implementing your favourite instruction set, which when you think about it, is incredibly implausible and impossible to prove. It's eerily similar to an unfalsifiable theological claim.
Then there is the silly argument that x86 chips don't exist anymore, when x86 chips have distinctive differentiating factors that make them unlike chips that implement other ISAs. The most obvious one is that x86 is primarily used in the personal computing and server space. This means the chips focus on high single threaded performance with large caches and large core counts plus swappable memory and storage devices, whereas most ARM and RISC-V devices target a completely different space, primarily embedded devices where everything is included on the PCB and there are very few external interfaces. You have to be pretty delusional that an unfalsifiable claim on an internal architectural detail of a CPU core somehow invalidates the rest of the silicon that happens to be on the same die.
I hate comments like yours because they are self defeating and require a lot of effort to debunk.
My disagreement with the article is mostly the following:
RISC-V is not an ISA, but an ISA generation framework.
If RISC-V would've standardized aarch64 1-to-1, the end result would've still been a huge extension mess, because a lot of people (RVI member) have different requirements and a very happy to build their own subsets, which would then be upstreamed because multiple vendors want the same subsets and compatibility between them. Obviously it would've been better, similar to if RISC-V spawned with RVA23 done, but development takes time and RISC-V International started, because people where already using RISC-V.
RISC-V also is the most DOSed ISA, with people proposing crazy stuff. Just the other day somebody proposed an instruction that would do up to 2^30 16-bit comparisons in one instruction at the largest VLEN. Because they wanted to improve their string processing usecase.
---
In my experience RVA23 matches aarch64 and x86 in uop count (without fusion), code density is better, instruction count is slightly higher. The biggest impact on the instruction count advantage of aarch64 over RVA23 is a single instruction, load-pair, which gets cracked at decode in every high-performance implementation, because it writes to to registers.
The Arm approach to code density is using multiple writeback instructions that have to be cracked and the RISC-V one is RVC. Both prohibit simple linear scaling of parallel decoding, so code density seems to have mattered to Arm enough to make the tradeoff worth it.
It’s kind of funny that all of the complaints about optionality apply equally to Vulkan. Google even created the same profile solution with “Android Vulkan Profiles (AVP)”.
I suspect Vulkan suffers from the same design by committee problem, which similarly caused it to miss seemingly basic features in the base spec that then need to be filled in with extensions and also made it too difficult for developers to want to move too.
- A big problem with extension detection RISC-V has is that there's no central authority mandating vendors to not overlap things (obviously, given RISC-V being an open standard), so basic bitmasks for supported extensions is generally rather problematic (and of course even if you collected a standardized bitmask of all extensions from all vendors, it'd grow quite massive quite quickly); you'd at least want some grouping/marking by vendor, if not full extension strings. That said, it would be nice to at the very least have some standard in-memory blob format if nothing else, that you could query from any OS/libc. (which maybe somewhat-exists to some extent with a C API meant for libc, but as-is still doesn't attempt to figure out vendor extensions).
- many, if not the vast majority, of aarch64 TBZ/TBNZ are probably branching on a boolean; something RISC-V can also of course do in one instruction. Generally, comparing instruction frequencies across ISAs is messy if not approximately meaningless due to different sorts of things existing for solving the same tasks.
- "Having this happen means that instead of a clearly-understandable crash you get ... well ... anything." - RISC-V will do you one better - it doesn't even guarantee a crash when an instruction isn't defined at all! Overlapping extensions is definitely messy for disassembly, sure, but that's also just basically unavoidable as long as RISC-V is open (see my first point). (perhaps there could've been stricter rules for reserved-for-standard encodings than reserved-for-vendor ones? of course still doesn't help vendor encodings, nor non-compliant vendors)
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.
The fact that it's only "competitive" with aarch64's code density is a solid black mark against RISC-V.
The only reason it's "competitive" is the compressed instructions, which means it's paying all the costs of variable length instructions, yet only getting marginal benefits. IMO a modern ISA taking advantage of variable length instructions should be able to absolutely smash the code density of a fixed width ISA like aarch64. At minimum, it should be competitive with x86 code density, if not smashing that too (because x86 has a lot of legacy baggage)
Compressed instructions aren't a bad idea for very small cores. They give you a decent code density boost with minimal added complexity.
But for large cores you either want to go full fixed length (like AArch64 and Qualcomm's proposal, which bought non-compressed RISC-V into the range of AArch64) or adopt a much more complex variable length scheme that can actually beat x86 on code density.
> The fact that it's only "competitive" with aarch64's code density is a solid black mark against RISC-V.
Arm uses complex instructions with multiple writeback, that require cracking, to improve code density.
RISC-V uses a variable length encoding to improve code density.
Both have anaougus decoding complexity, but RISC-V achieves higher code density, while impacting the cost of things before decode (how much, idk).
There's a huge difference between 2/4 byte variable density and 1-15 byte variable density. And as I've said in other places, my experiments showed that it ended up being kind of across the board less than half a pipeline stage to handle C instructions, kind of orthogonally to decode width.
It is a different front end design, so that's why Qualcomm didn't want to reengineer their aarch64 core more than they had to, but the rest of the riscv community was right to not embrace it.
Not to mention that a lot of the aarch64 derived pieces in the proposed qualcomm extension are almost certainly patent encumbered. Qualcomm can absolutely handle just about any patent fight, but other risc-v companies can't.
I agree that 16-bit/32-bit variable length would struggle to beat x86. But I suspect it could have gotten close, simply because x86 wastes a huge amount of its advantage on legacy cruft.
The important point is that there is no reason why a 16-bit/32-bit encoding shouldn't have smashed Aarch64's 32-bit only code density.
My secondary point, is that why should RISC-V limit itself to just 16-bit/32-bit? It has the encoding space set aside for 6 bytes, 8 bytes, 10 bytes and all the way up to 24 bytes (which is overkill). If it's already paying the variable length tax, it should be making better use of it. IMO, a 2, 4, 6, 8, 10... byte scheme should be able to massively improve on x86's code density.
> I agree that 16-bit/32-bit variable length would struggle to beat x86. But I suspect it could have gotten close, simply because x86 wastes a huge amount of its advantage on legacy cruft.
I'm saying the opposite. Maybe some theoretical CISC-V would leave RISC-V behind, but x86(and -64) makes wild choices for instruction density, and RV64GC already clearly beats x86-64 in .text density.
> My secondary point, is that why should RISC-V limit itself to just 16-bit/32-bit? It has the encoding space set aside for 6 bytes, 8 bytes, 10 bytes and all the way up to 24 bytes (which is overkill). If it's already paying the variable length tax, it should be making better use of it. IMO, a 2, 4, 6, 8, 10... byte scheme should be able to massively improve on x86's code density.
There's nonlinear issues as you add more options. A 16-32 decoder is pretty simple, a 16-32-48 isn't the worse thing in the world (and a 32bit immediate might make it worth it), but you start to hit weird explosions in gate count once you go much past that. Hence x86's splitting into essentially multiple front end banks in modern designs, and even then typically only has one decoder per bank that can decode everything, and even that takes multiple cycles for some instruction sequences, even just to discover the length.
The larger lengths in the RISC-V spec are more targeted towards bespoke stuff like GPGPU that's maxing out issuing a single instruction per instruction stream anyway. When you look at shader machine code, it's clear density was essentially an afterthought, but they love them some 64bit wide instructions. Which unsurprisingly is pretty much the same width of vertical microcode in archs that still do such a thing.
> and RV64GC already clearly beats x86-64 in .text density.
Maybe I'm misremembering. Or maybe the numbers I'm remembering took into account the fact that most compilers unroll more aggressively on x86 than on targets they consider to be "embedded" (another pet peeve of mine)
I stand by my assessment that the code density of rv64gc (and especially rv64g) is lower than it would be if they had actually put a focus on code density.
> A 16-32 decoder is pretty simple, a 16-32-48 isn't the worse thing in the world (and a 32bit immediate might make it worth it), but you start to hit weird explosions in gate count once you go much past that.
Not sure I would say 16-32 is simple, certainly massively simpler than x86. My point is that you have already paid the tax for going variable length, and 16-32-48 isn't that much more complex. And probably worth it for 32-bit immediate/offsets.
And maybe 16-32-48-64 is worth it... Hard to tell, but I wouldn't entirely rule it out without study. The advantage would either be immediates/offsets that are too big to fit in 48 bits. Or some kind of VLIW style scheme which actually packed three 20-bit instructions into aligned 64-bit packets. (Or other mixtures of sizes like 30-30, 30-15-15, 40-20, or 15-15-15; We are talking about a complete break from RISC-V. There is a thread somewhere on HN where we brainstorm something like this).
But beyond that, no point really. Just pointing out that RISC-V reserved the space.
Maybe I need to prototype the 64-bit aligned packets idea someday, at least far enough to get instruction density numbers.
It is, with a prefix encoding, you can reuse the RVC decode path 1-to-1 and get the 48/64-bit instruction starts with a simple bitshift (or simply handle the 48/64-bit instructions via the fusion path). This seems to be the encoding direction RISC-V is headed in.
The article makes the case that RISC-V achieved code density the wrong way. Instead of compressed instructions, ARM has fixed-size instructions with richer semantics.
Why is he complaining about everything being optional in RISC-V? Isn't that the whole idea of RISC-V? The market can sort it out for themselves. RISC-V is already dominant in the MCU space despite its flaws, and many of them will be solved in due time.
Most MCUs are used for dead-simple solutions, like electric blankets and microwaves with segment displays or LEDs. Whether their interrupts are handled in 44 or 22 cycles doesn't really matter that much.
And RISC-V does have a link register, making returning much faster when the parameters for the interrupt can all fit in registers and no external memory access is needed, as is the case with most MCUs which put the stack in RAM. To fetch the return address an external memory access is always needed even if there are no parameters.
He explains, at length: there is no sane way to determine what the hardware you are running on actually supports, and so there is no sane way to ship compiled code that is both compatible and performant.
We already had the mystery meat CPU wars several decades ago. We know how to make sane ISAs now and should be past that.
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.
He actually explains this too. You only know at compile time what you're building for. For example with microblaze-V, I often tweak what ISA I'm generating. If I ran the same elf without thinking about it, who knows what could happen given the instruction collision problem
Well, misa won't be in most cases since you'll be running ins mode rather than m mode for most kernels on an application core (and misa won't tell you about the X* and Z* extensions).
But you'll practically be passed a device tree from SBI that will tell you.
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.
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.
I'm not an embedded programmer myself, but from what I've heard... it's actually a pretty big assumption that the software people know what model hardware they're running on.
Especially consider the possibility that a product manager decides to swap out the core for a different core to save 5¢ on the BOM. Does the product manager know to ask if the two cores follow the same RISC-V profile? Do the software programmers think to ask? How about communicating the change to all of the vendors or contractors providing you binary blobs? I don't know how likely it would be for a scenario like he author here describes, but it is definitely a plausible scenario.
Even if the core was supported just fine, all of the IO mux stuff is pretty much guaranteed to be different even with the same chip in a different package.
I worked on a project porting from an STM32L073 to a STM32U073, which management were assured was a complete drop in replacement. Well, it was only in the sense that you could drop one onto the old PCB. It became a running joke how many software compatibilities we ran into. My favourite was an "LCD clock disable" bit became "LCD clock enable". And this was for a specifically chip designed to be an easy replacement.
I don't think I've read a more "doesn't actually know anything about how software is produced, but with absolute confidence knows everything about it" post in a very long time.
This ensures (in theory, at least) that even if you're using your linux distribution's openssl library which is more generically targeted, you will get optimal/native runtime performance for your actual CPU.
Both of your post are actual ad hominem towards OP. In the first, you just said they didn't know how software is developed, without elaborating. With this in mind, their reply is less of an ad hominem and more of an inquiry. In the next, you accuse them of having a fragile ego and being a kid. Not very insightful.
> 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.
In practice, this is not the case. The scenarios mentioned in the article involving binary blobs are pretty common, as well as other similar scenarios.
Really, I'm going to go out and say it bluntly: it is just completely freaking stupid to make an architecture where everything is optional but you have no way to query what's present. If you're going to go the optional-pieces route, you have to have a query mechanism of some sort. As the article explains, you cannot even trap instructions on RISC-V to figure out what your core supports, because bad instructions might belong to some other option. Complete. Idiocy.
>"RISC-V is already dominant in the MCU space[...]"
Where are you getting the idea that RISC-V is dominant? As someone who works in this space, that doesn't jive with my experience or the sources I've seen.[1] 32-bit microcontrollers only recently achieved a majority market share for gosh sakes!
RISC-V is claiming that they have achieved 25% market share across selected segments, but they're still behind ARM (and x86).[2]
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.
Because nobody will write software for 300 unique hardware variations of a platform that have inconsistent capabilities. Consistency is one of the reasons why x86-64 with extensions like like SSE, AVX2 etc is popular.
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.
Every time I've seen someone use an 8051 in the past twenty years, it's had new, bespoke software written for it. They were more used because they were a known quantity with the patents obviously dead rather than support for existing codebases.
Interesting comment. I suspect without solid facts that new bespoke stuff is mostly either 1) some ARM variant, or 2) some rando US$0.001 Chinese uproc. I think 8051 survives because there's many decades of experience using it, but as I understand the cool kids going into embedded don't think the boomers 8051 is fun and the pool of talent is shrinking fast. SO we'll see what the future holds.
Those aren't mutually exclusive. Some of the sophgo and bouffalo chips have 8051s for always on cores, and riscv for the main cores.
They didn't choose 8051 there for experience, but because it was a tiny core with a decent IPC they could license for a small part, then focus on the main cores. I wouldn't be surprised if they eventually switch to riscv there too.
Also, these 8051 cores tend to be extremely diverse. I don't think I've come across cores from different manufacturers that were actually compatible for real code. They all seem to want to handle accessing 16/32 bit memory differently, have different interrupt details, etc.
Interesting...I don't know much about sophgo and bouffalo chips. Not surprising since the 8051 is patent-free these days. Something I found crazy is how many places someone embedded an 8051 core. Like the tire pressure monitor in every tire these days. Fun stuff.
I really don't know anything about this space, but you just said that 8051 is dominant because it has one dominant architecture since the 70s. It has hundreds of manufacturers making identical parts.
As you say, software matters. If the Software can't run because of hundreds of extensions that can't be checked for, then you're going to pick a target that works, no? So in fact the ISA matters most: which ISA has the most software? Which ISA means my software runs on the most devices?
If the Software can't run because of hundreds of extensions
The software in the x86 world runs because there aren't hundreds of mutually incompatible extensions. I think the last time there was a major completely incompatible x86 ISA divergence was AMD "3DNow" vs other SIMD extensions. AFAIK the rest were "processor X got feature Y later than competitor Z".
Which ISA means my software runs on the most devices?
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.
> The second category for big-compute is actual desktops and SBCs that do interactive computation, browsing, gaming, and other such "desktop work". I do not expect RISC-V to be a serious player at the top of this market. Simply put, the architecture is not designed for it, as pointed out above. Additionally, this market has the margins to afford licensing a much-better-designed aarch64 core from ARM, and gain proper support from a much larger corpus of software. Before you get your megaphone to shout about "openness", please note that the openness of the RISC-V spec is not relevant here at all, because an open spec does not magically materialize a well-designed out-of-order core for you for free. And if someone were to design a good out-of-order core, they would not be giving it away for free. An open spec does not mean every implementation is free.
I basically disagree with this. Not because this isn't the current state of things (it absolutely is), but because we're at a bit of an inflection point where mooore's law has proved itself to be an scurve, and we're very clearly well into the top half of it. From that, gate counts per core will also start to ossify, and that means the longer latency for getting an open core design off the ground initially will also start to make sense.
I'm not sure the gate count argument works in RISC-V's favour.
While RISC-V is quite optimised for gate count for small cores; In large wide OoO cores the variable length encoding really bulks out the decoders.
You basically have the same requirement as x86, where you have to attempt to decode a 32-bit instruction every 16-bits (because there is no alignment guarantee for 32-bit instructions), and then cancel out the invalid ones. It's not quite a bad as x86, you only need to look at two bits, but it still forms a long dependency chain, and probably requires at least one extra decode stage with complex routing to pick out all the valid instructions.
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.
Yes... but then you are kind of wasting a pipeline stage on nothing more than length decoding.
I suspect a design with a full decoder every 16-bits might actually win on everything but gate count, mostly because it can deal with variable length instructions and variable number of μops per instruction in the same step. A decoder that doesn't output a μop because it was clobbered by a previous instruction, can be handled the same was as a decoder that didn't output a μop because of μop fusion.
Actually, that approach might actually eliminate the need for the extra pipeline stage (just at the cost of gates).
It's certainly not a deal breaker. But it's a valid criticism of the ISA.
I said easily less than half a pipeline not a full stage. Everything kind of shifts around a bit because of that, and it ends up being a pretty different design than a fixed width front end because of it (hence qualcomm's objections), but it's not clearly worse.
And for better than aarch64 density, it seems to make a lot of sense.
Ok, so you doubled the number of decoders, how is that not significantly better than x86?
I'm not even sure you have a point with regards to it being a valid criticism. Doubling the silicon area for instruction decoding probably costs nothing, because if you have a simple decompression stage, the maximum number of decoders is already doubled in the first place, because you're hypothetically encoding twice as many instructions to begin with. If you can double the decoders in the decompression stage, you can probably get rid of a separate decoding stage altogether and thereby reduce the cost to literally nothing.
Look, it might not be obvious but in university I once had to design an ASIP and then do the floor plan with Cadence and the area of the SRAM dwarfed everything to the point where my ASIP was a tiny vertical column in-between two SRAM chips. I personally was shocked by the fact that I struggled to even find my ASIP on the floor plan, because it was maybe ten standard cells wide in-between the SRAM blocks. Like, ridiculously tiny to the point where it is hard for me to even care about the area the ASIP took up.
> you can use the same base trick behind a carry lookahead adder
YESSSS.
I've been pointing this out for years and years.
By the point that you're looking at the same propagation delay as a common 64 bit adder you're decoding 64 chunks of 16 bits per cycle. That's 128 bytes, or a 32-64 instructions wide decoder.
That is so much wider than anyone is making or contemplating — or that even makes sense given the size of basic blocks — that it's just a non-issue.
And even if you go to those extremes, the biggest nay sayer says the cost of the design flaw will require you to double the number of decoders, which hardly sounds like a big deal to me.
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.
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.
Linux is decent for its core use cases, but it is far from a solid pro-grade OS in a lot of areas... and in the areas it did get there, it took a long time to get there.
If those people build cores like linux kernel is built design-wise, i will PAY to watch the spectacle.
You do realize that Linux got basic SMP support 3 years after NT, and it was shaky for a while after? It still does not have reliable sleep-wake. And it only added native async file i/o in 2019, while NT has had it on the same hardware since 1993? So.. i'll expect an in-order core with an IPC south of 0.5 that cannot exit low power sleep 30% of the time in a decade or so.
> You do realize that Linux got basic SMP support 3 years after NT?
Linux started about three years after NT did. And NT could only support 64 processors for a long time when Linux could support thousands.
> It still does not have reliable sleep-wake.
Neither does NT really. Both depend on ACPI for the systems you're talking about, and it's the platform interface that's ultimately fucked.
> And it only added native async file i/o in 2019, while NT has had it on the same hardware since 1993
And has beaten NT on IO throughput for decades, and even now windows ships with a linux kernel integration because running Linux on a hypervisor is far batter for filesystem ops than running those on NT.
> So.. i'll expect an in-order core with an IPC south of 0.5 that cannot exit low power sleep 30% of the time in a decade or so.
There are already open source OoO RISC-V cores.
But the point originally isn't to be some Linux fan boy (I've written a decent amount of NT kernel code, and have a lot of respect for NT and the things it did right). It's to point out how the upcoming changes inherent to how chips are made and the latencies between gate count targets will better support open collaboration. And once that's supported properly, open source has a tendency to kind of snowball.
What does this have to do with anything? You do know that a bunch of American corporations are shipping RISC-V cores, right? Including Jim Keller's current company, Tenstorrent.
I mean, Apple is different from pretty much every other manufacturer here. They collborated in the design of aarch64, and a rumored to own a lot of the base IP themselves which they've cross licensed with ARM. It's very close to AMD:Intel::Apple:ARM when it comes to aarch64. That heavily changes the licensing costs. My point isn't that RISC-V is markedly better, but instead that it's equivalent from a perf achievable from in the same nexus of PPA and NRE effort. So there's no reason for Apple to take the pain of a leap with no real gain, but NRE losses.
I would expect to see RISC-V Android phones (probably initially out of China, despite ARM China) within the next few years. They've been busy bees since RVA23 was ratified with a bunch of Chinese companies making changes to optimize AOSP for RVA23. I've also heard on the grapevine that NT already has a RISC-V port internally, but take that with whatever grain of salt you feel like. But Microsoft has already been contributing to the RISC-V specs (they contributed to Ztso for instance).
There is zero chance that Apple doesn't have MacOS and iOS running on RISC-V in the lab.
They did that with x86 and Arm half a decade before any announcement about a switch, not to mention a number of other ISAs that didn't make it to shipping (e.g. M88k) and probably ones that word has never leaked about. IA64, anyone?
They're too large and rich and risk-averse to *not* do it.
> […] we're at a bit of an inflection point where mooore's law has proved itself to be an scurve […]
Well. May's law[0], which states that:
Software efficiency halves every 18 months, compensating Moore's Law.
effectively counterbalances Moore's Law and, with continued technological process improvements and optimisations, the proverbial arm's race is likely to continue for a very, very long time – just a few days I was reading a wonderful article from 1998 on the state-of-the-art DEC Alpha 21264 CPU which mentioned the 21264 and POWER3 as the world's most complex CPU's each boasting 15+ million transistors and also mentioned the equally state-of-the-art 0.18 micron processes. The 3 old year M3 Max design, in comparison, supplies over 90 billion transistors to the mainstream consumer.
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.
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.
I feel like that's largely mitigated by profiles. RVA23 is really looking like it'll be the modern base target used for high performance application processors and it makes mandatory pretty much everything you'd want for those use cases, and other comments by people familiar with designing RISC-V CPUs mention that the variable length encoding can be dealt with in a very simple manner that doesn't even add another pipeline stage so it doesn't seem like it's all that big of a deal while also bringing in benefits in code size reduction. Not everyone is adopting it, but several major players have set the stage by mandating it.
> Say you want to store a byte to a register plus offset. What range of offsets can a [compressed] 16-bit instruction encode? Zero through three.
If a compressed instruction could load or store a word to a word-scaled offset 0-3, relative to a register base address, that would be quite useful. It could be used for accesses to all structures four words or smaller.
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.
I was excited when I heard about the project just after it started.
However, past experiences taught me to wait before getting excited about the new 'shiny thing'. I did it differently with RISCV. I waited.
I am glad I did.
It took a long time for actual silicon to appear.
Also, the silicon today has all the facepalming special cases mentioned in the article.
Its almost like those old soviet era cpus that had the list of bad instructions handwritten on the package.
Overall, RISCV was a minor spin on MIPS, but without really learning from other processors.
So why is everyone still pushing for it?
It has the words 'open' on it. People pattern match on that marketing.
As part of that marketing, they also pushed this attitude from the project... 'RISC won'.
I think Chester Lam said it best when he wrote his essay stating that RISC didn't win... OoO archs won. I couldn't articulate that nearly as well as he did.
If you haven't read it, I recommend it.
So, yeah, here we are.
Many people will follow the bandwagon, but they will find that RISCV will not make a significant difference.
I am glad we still have Arm (in all its many forms), x86, and others.
(btw, despite my username, I don't think x86 is the best either :-)
Also, if you aren't trying to ship a product, you can experiment with ISAs on an fpga.
Yes, fpgas are a lot slower, but they are also a lot more fun.
Especially with the great work done to create open source toolchains.
Heck, if you are really serious (slighly crazy), you can build your own chip.
For the foreseeable future ASIC shuttles are available at prices under $10k. (again, you have to be a little crazy)
I'd say RISC won, when you consider how "RISCy" x86 is[1] compared to the ur-CISCs (68k, VAX) that RISC projects were in opposition to.
[1] Not because of often-called "risc like" microcode engine, but because the most complex addressing mode on x86 usually decodes two microinstructions, and decodes in single cycle. In comparison VAX needed separate pipeline for instruction decoding.
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.
Sure, the constellation of features is no longer a general purpose computer in the retail context, but rather an ASIC appliance the ends up incompatible/useless rather quickly.
Maybe Gentoo could tame that level of chaos... or people just buy ARM64 again knowing the software ecosystem already works. =3
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.
Until people admit they made the same mistake as ARM6 fragmenting the architecture focus, its adoption will probably continue to stall under each firms hubris. =3
> After being asked for the Nth time to explain, I decided to put it all down in one place so that I could simply link to it when asked next.
Bookmarked, because I've needed the same.
The worst part of all this is that they really should have known better by now. In 1980 you could make these kinds of mistakes, because this was pretty new territory. In 2020, doing this just makes you stupid. Or ignorant. Or both.
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.
Things are generally defined by the neccessities that led to their creation. x86 was designed for home PCs and has been forced to evolve with PC technology. ARM was designed to take advantage of RISC architecture, and were forced to evolve with the mobile industry. What was RISC-V invented for, and what external forces have acted on it since then?
I think a lot of this criticism is completely true. However it's also overblown. I do think the ISA matters, but little mistakes like these definitely don't matter enough to preclude making M-series class chips. The reason it hasn't happened yet is simply time. It takes a really really long time to build up to that level of performance.
They've definitely gone overboard on the optionality stuff though. I don't think it matters too much for the actual CPU design but it makes verification and writing portable software a huge pain. Profiles definitely help but still...
Oh also I feel like you could probably come up with an equally compelling list about any other ISA. It's not like the fact that something has flaws means it's bad.
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).
When I looked into mconfigptr some years ago I thought it looked like a swirling vortex of pain that might produce something useful some day. Good to see it's still being worked on. Sad to hear ASN.1 is still involved.
I added an "misa but more bits" register to my core, using the bit assignment from the RISC-V C API, so at least until then I know what extensions each instance of my core implements. https://wren.wtf/hazard3/doc/#reg-h3.misa
Linux folks seem to have already put a lot of the mconfigptr info into the DT blob anyways.
ALL chip designs are an exercise of minmaxing these 3 variables:
1) power
2) performance
3) die area
SOME chip designs also care about a 4th:
4) die area.
NO design has the best of all...it is impossible since you have to trade 1 for another. The reason x86 has been dominate for so long is that is strikes a good balance across all areas, especially #4. A good balance is what you need for a good chip.
EDIT: oh and you can't beat the system I mentioned above. The laws of physics are the reason why.
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.
> What does a cheap microcontroller core need? Let's inspect what they are used for. Typical use cases are to interface with and quickly reconfigure hardware blocks in a larger chip, eg in an MP3 player, an SD card, or a USB stick. The hard work is done by custom IP and the CPU core is just there to occasionally prod a register or configure something.
So … use RISC-V as the strawman, and create a community-based RISC-6 that doesn’t have these weaknesses? Better to get in now before it becomes too solidly entrenched.
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.
You're vastly underestimating the amount of work that has gone into RISC-V that would need to be redone. It's not just a spec. There's an absolute mountain of software and hardware supporting it.
It's clear that RISC-V started as an academic exercise (albeit from a group with esteemed credentials) and they had to bolt on these hacks to make it work in industry.
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.
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.
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.
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.
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.
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.
What's stopping them? They can trivially claim it infringes any number of patents...
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?
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.
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.
* 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.
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.)
Oh, that's not completely true. Intel 64 and AMD64 are not identical and they certainly have encodings that behave differently. As an example: f3 41 90 is pause on Intel, but xchg r8d, eax on AMD (granted, this is not a canonical instruction encoding). 66 e9 xx xx yy yy is a unconditional jump to a 32-bit relative offset on Intel, but on AMD, the offset is 16-bit only (yy yy are the start of the next instruction). x86-64 is typically used to refer to the very large common subset, but this doesn't mean the implementations behave identically.
There are also some weird corner cases where CPUs aren't 100% backwards compatible, just backwards compatible enough for the software that matters.
User-mode feature detection is usually used to select paths for acceleration instructions, like SIMD or crypto. The overlapping RISC-V instructions don't fit in that category: they're compressed versions of basic functions, mostly used in epilogs/prologs, which would be unconditionally compiled in.
There are no overlapping encodings in the 32-bit encoding space and I'm really hoping it stays that way.
> To the extent that there are lessons to be learned, RISC-V should have learned them.
Yeah, I think I agree with this. Also I wish I had been there when Andrew Waterman was writing his master's thesis so I could ask him not to include Whetstone in his size benchmarks, so that we might have left that encoding space free and avoided this conversation :-)
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.
> 1. Supported in mainline LLVM and GCC.
Which pretty well encapsulates the ecosystem requirements.
It turns out that the cost of waiting years for an ISA change is more costly than fixing whatever problems it has.
What the heck is this guy's problem? Just about every thing he mentioned as a problem is not a problem in practice. Too many options? Who cares, you're not trying to write code that runs on every possible configuration. Either you're writing embedded firmware and know exactly what core you're using, or you're writing an application that runs in an operating system and that system has a minimum ABI like RVA20 or whatever.
Array accesses take an extra instruction? Either you're in a tight loop walking a tiny array and you don't do the full offset calculation per step, or you're walking over an array in RAM and you're bottlenecked by the memory bus.
Hell, 90% of his arguments are "You can't detect X at runtime from user code without relying on some extension" - Yes, that is totally fine. Either you know your target CPU, or you don't - and then you ask your OS for details. This is not some dealbreaker.
From the article - "For example, if you are writing a kernel and want it to support all RISC-V cores" - NOBODY IS DOING THAT. You target a platform spec, not the combinatorial explosion of everything from RV32E to RVA22 or whatever the latest is.
You want to distinguish S mode from M mode? WHY DO YOU NOT ALREADY KNOW THIS?
Instruction encoding is weird? WHO CARES, the decoding is like eight lines of Verilog.
"Who can predict how their binary will act when a floating point store silently becomes a double-register move or a jump instruction, or vice-versa?" - THIS DOES NOT HAPPEN IN PRACTICE.
Guhhhhh, I don't get it. This guy has some vendetta and either has not shipped any risc-v code or is just in love with his own personal favorite instruction set.
Not that linking/loading is a super hot path people generally worry about.
RISC-V is not an ISA, but an ISA generation framework.
If RISC-V would've standardized aarch64 1-to-1, the end result would've still been a huge extension mess, because a lot of people (RVI member) have different requirements and a very happy to build their own subsets, which would then be upstreamed because multiple vendors want the same subsets and compatibility between them. Obviously it would've been better, similar to if RISC-V spawned with RVA23 done, but development takes time and RISC-V International started, because people where already using RISC-V.
RISC-V also is the most DOSed ISA, with people proposing crazy stuff. Just the other day somebody proposed an instruction that would do up to 2^30 16-bit comparisons in one instruction at the largest VLEN. Because they wanted to improve their string processing usecase.
---
In my experience RVA23 matches aarch64 and x86 in uop count (without fusion), code density is better, instruction count is slightly higher. The biggest impact on the instruction count advantage of aarch64 over RVA23 is a single instruction, load-pair, which gets cracked at decode in every high-performance implementation, because it writes to to registers.
The Arm approach to code density is using multiple writeback instructions that have to be cracked and the RISC-V one is RVC. Both prohibit simple linear scaling of parallel decoding, so code density seems to have mattered to Arm enough to make the tradeoff worth it.
it does make me wonder what prompted them to join. it would suggest to me there are forward looking people in Brazil’s government. I am impressed.
There are actually many of those. But Risc-V has become, through effective marketing, the Schelling point for anybody who wants to avoid the x86 and Arm ecosystems, both for the rent-seeking behaviors you mention, and also, in some instances, for security reasons.
And, as others have mentioned, the ISA doesn't really matter. As long as it's agreed upon, then the CPU vendors can optimize on one side, and the compiler writers on the other side.
Sure, Risc-V has its warts, but you can certainly say the same about all the rest.
Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are:
* Taking up valuable compressed instruction space; each compressed codepoint has an opportunity cost of 64k uncompressed ones.
* Limited in which registers they can use (usually x8..x15).
* Often clobber their input operand instead of giving a free move.
Also consider that the frequency data that drove the RVC compression decisions was driven by the lack of architecturally fused instructions like sh*add, so any arguments you derive from that data are circular. An instruction can be a good uarch fusion target because it's compressed, and a good compression target because you didn't fuse it in the architecture.
I think designing for uarch fusion in your ISA is coming at it from the wrong end. Fusion is something uarch designers do to make up for shortcomings in the ISA.
Not sure if there's an impact caused by the late addition as opposed to always having them, but considering this is a fairly core thing what a program does, not sure what degree of fragmentation this causes on the level of compilers and hardware.
x86 effectively killed innovation in the SIMD space by making instruction set support so fragmented, that people had to target the decade-old lowest denominator.
Intel has being fusing `CMP` and `Bcc` since Core 2 and AMD since Zen 1.
This is
- already one instruction in RISC-V
- an *extremely* common pattern, often occurring once every 5 or 6 instructions.
But *code size* is a demonstrable fact.
RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23.
Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of various binaries, individually or in aggregate.
In 32 bit ARMv7-M / ARMv7-A had a small code size lead over RV32IMAC, but this is reversed in modern RISC-V e.g. if you look at RISC-V Hazard3 vs Arm Cortex-M33 in the RP2350 (Raspberry Pi Pico 2) where you can trivially change one option setting in your project and recompile and test.
The only exception is that the M33 has a single-precision FPU, which neither the Hazard3 nor the Cortex-M0+ in the RP2040 have.
Forgot to say “RISC”. Cause else: amd64
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.
What you find may or may not match reality. In this instance, I don't believe it does.
> We do not particularly care how complex the specification becomes because the vendors will implement it. We shall leave it to them.
This, of course, is a silly argument. Yet, it is completely orthogonal to the one I was making, and is 180 degrees away from the complaints leveled at Risc-V which are that it is an overly simplistic, nay childish, specification, written in crayon by kindergartners.
> 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.
I find this statement accurate, yet condescending. Who the fuck thinks that they are? Claiming that this is an "issue" with my statement appears to be a reductive argument that I have not thought it through. To be blunt, this statement reveals a hell of a lot more about your ignorance on this issue than mine.
> It is not an accusation, it is merely an acknowledgement that vendors tend to behave like vendors.
And yet, we have seen this play out in x86, with Intel v. AMD, and it worked exceptionally well.
> An equally plausible outcome is that they will not – or that they will each implement mutually incompatible interpretations whilst proclaiming full compliance.
Of course, AMD and Intel were always trying to one-up each other, but that is tempered by the necessity for their improvements to be supported by compilers. By the time an improvement is well-supported, the other side has caught up.
With Risc-V this is even more likely to be the case, because proprietary extensions will simply not be that well supported by major compiler vendors, who have a hard enough time keeping up with the ratified ones.
But then I wanted to be compatible with off-the-shelf toolchains and binaries, and I found myself needing to extend the ISA profile to RV64GC. Not a huge lift, but it involved pulling in a softfloat library. That got me as far as booting Alpine linux.
And then I wanted to be able to boot Ubuntu, which needed RVA23, which was comparatively a much bigger lift, involving the vector instruction set among many other things. At this point I think I'd have been better off just emulating aarch64.
Debian has no plans to require more than RV64GC.
RVA23 is a very good thing in certain markets, but nothing forces you to support it for a personal project.
Also this is one of the reasons I think Zfinx is a better option for embedded (i.e., the standard FP instructions operate on x registers instead of f registers): 31 registers is plenty to hold a mixture of integer and floating-point values, and you avoid the worst-case context save penalty.
The reality? The fastest "available" RISC-V CPUs don't match the best chips in terms of speed, power consumption, or die area. "available" obviously means the chips that have been released to the public and can be independently benchmarked.
I do think that is okay, however I also think that those involved with RISC-V aren't helping much, and current attempts at standardizing seem to be just creating a bigger problem.
That being said, RISC-V does seem to perform well in specific niches.
The conclusion is honest, and you can of course brute force any ISA into any role. I used to loathe x86 for that reason, but now that I'm older I respect the game.
It just blows my mind sometimes when designers don't learn insanely obvious lessons from the past, basic stuff like "complexity is evil" and "make the fast path overlap with the most common use cases" and "a standard with N optional extensions is actually N! (N factorial) standards."
That being said all real world architectures seem to have messy corners and warts. RISC-V was a chance to do away with a lot of that and they... didn't?
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?
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.
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.
As a fellow olderster, I can't help but think that after almost 50 years of "ISA X is sooooo much better than x86 it's obvious ISA X is the future and x86 will be dead Real Soon Now (for whatever todays version of x86 is)" I can only shake my head ruefully and say "ping me when that happens".
Controversial Take (that history proves isn't): Software matters; ISAs don't.
Today, we have Intel and AMD, and some bit-player embedded folks.
Humans are weird.
They always had a much cleaner instruction set internally, going back to the 8086.
If what they say is true, then x86 won because ISA doesn't matter, precisely because ISA is the public instruction set architecture. If you can convert anything to a better representation then the argument of exposing the better representation doesn't actually follow.
Additionally, you are claiming that an internal implementation detail that only Intel and AMD know about is secretly implementing your favourite instruction set, which when you think about it, is incredibly implausible and impossible to prove. It's eerily similar to an unfalsifiable theological claim.
Then there is the silly argument that x86 chips don't exist anymore, when x86 chips have distinctive differentiating factors that make them unlike chips that implement other ISAs. The most obvious one is that x86 is primarily used in the personal computing and server space. This means the chips focus on high single threaded performance with large caches and large core counts plus swappable memory and storage devices, whereas most ARM and RISC-V devices target a completely different space, primarily embedded devices where everything is included on the PCB and there are very few external interfaces. You have to be pretty delusional that an unfalsifiable claim on an internal architectural detail of a CPU core somehow invalidates the rest of the silicon that happens to be on the same die.
I hate comments like yours because they are self defeating and require a lot of effort to debunk.
RISC-V is not an ISA, but an ISA generation framework.
If RISC-V would've standardized aarch64 1-to-1, the end result would've still been a huge extension mess, because a lot of people (RVI member) have different requirements and a very happy to build their own subsets, which would then be upstreamed because multiple vendors want the same subsets and compatibility between them. Obviously it would've been better, similar to if RISC-V spawned with RVA23 done, but development takes time and RISC-V International started, because people where already using RISC-V.
RISC-V also is the most DOSed ISA, with people proposing crazy stuff. Just the other day somebody proposed an instruction that would do up to 2^30 16-bit comparisons in one instruction at the largest VLEN. Because they wanted to improve their string processing usecase.
---
In my experience RVA23 matches aarch64 and x86 in uop count (without fusion), code density is better, instruction count is slightly higher. The biggest impact on the instruction count advantage of aarch64 over RVA23 is a single instruction, load-pair, which gets cracked at decode in every high-performance implementation, because it writes to to registers.
The Arm approach to code density is using multiple writeback instructions that have to be cracked and the RISC-V one is RVC. Both prohibit simple linear scaling of parallel decoding, so code density seems to have mattered to Arm enough to make the tradeoff worth it.
I suspect Vulkan suffers from the same design by committee problem, which similarly caused it to miss seemingly basic features in the base spec that then need to be filled in with extensions and also made it too difficult for developers to want to move too.
- A big problem with extension detection RISC-V has is that there's no central authority mandating vendors to not overlap things (obviously, given RISC-V being an open standard), so basic bitmasks for supported extensions is generally rather problematic (and of course even if you collected a standardized bitmask of all extensions from all vendors, it'd grow quite massive quite quickly); you'd at least want some grouping/marking by vendor, if not full extension strings. That said, it would be nice to at the very least have some standard in-memory blob format if nothing else, that you could query from any OS/libc. (which maybe somewhat-exists to some extent with a C API meant for libc, but as-is still doesn't attempt to figure out vendor extensions).
- many, if not the vast majority, of aarch64 TBZ/TBNZ are probably branching on a boolean; something RISC-V can also of course do in one instruction. Generally, comparing instruction frequencies across ISAs is messy if not approximately meaningless due to different sorts of things existing for solving the same tasks.
- "Having this happen means that instead of a clearly-understandable crash you get ... well ... anything." - RISC-V will do you one better - it doesn't even guarantee a crash when an instruction isn't defined at all! Overlapping extensions is definitely messy for disassembly, sure, but that's also just basically unavoidable as long as RISC-V is open (see my first point). (perhaps there could've been stricter rules for reserved-for-standard encodings than reserved-for-vendor ones? of course still doesn't help vendor encodings, nor non-compliant vendors)
I really do hope that the arch is eventually able to fix this. Better that there be an open ISA than them all be closed IMO.
Such as? I can't think of anything it does better for high performance cores.
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.
The only reason it's "competitive" is the compressed instructions, which means it's paying all the costs of variable length instructions, yet only getting marginal benefits. IMO a modern ISA taking advantage of variable length instructions should be able to absolutely smash the code density of a fixed width ISA like aarch64. At minimum, it should be competitive with x86 code density, if not smashing that too (because x86 has a lot of legacy baggage)
Compressed instructions aren't a bad idea for very small cores. They give you a decent code density boost with minimal added complexity.
But for large cores you either want to go full fixed length (like AArch64 and Qualcomm's proposal, which bought non-compressed RISC-V into the range of AArch64) or adopt a much more complex variable length scheme that can actually beat x86 on code density.
Arm uses complex instructions with multiple writeback, that require cracking, to improve code density. RISC-V uses a variable length encoding to improve code density. Both have anaougus decoding complexity, but RISC-V achieves higher code density, while impacting the cost of things before decode (how much, idk).
It is a different front end design, so that's why Qualcomm didn't want to reengineer their aarch64 core more than they had to, but the rest of the riscv community was right to not embrace it.
Not to mention that a lot of the aarch64 derived pieces in the proposed qualcomm extension are almost certainly patent encumbered. Qualcomm can absolutely handle just about any patent fight, but other risc-v companies can't.
The important point is that there is no reason why a 16-bit/32-bit encoding shouldn't have smashed Aarch64's 32-bit only code density.
My secondary point, is that why should RISC-V limit itself to just 16-bit/32-bit? It has the encoding space set aside for 6 bytes, 8 bytes, 10 bytes and all the way up to 24 bytes (which is overkill). If it's already paying the variable length tax, it should be making better use of it. IMO, a 2, 4, 6, 8, 10... byte scheme should be able to massively improve on x86's code density.
I'm saying the opposite. Maybe some theoretical CISC-V would leave RISC-V behind, but x86(and -64) makes wild choices for instruction density, and RV64GC already clearly beats x86-64 in .text density.
> My secondary point, is that why should RISC-V limit itself to just 16-bit/32-bit? It has the encoding space set aside for 6 bytes, 8 bytes, 10 bytes and all the way up to 24 bytes (which is overkill). If it's already paying the variable length tax, it should be making better use of it. IMO, a 2, 4, 6, 8, 10... byte scheme should be able to massively improve on x86's code density.
There's nonlinear issues as you add more options. A 16-32 decoder is pretty simple, a 16-32-48 isn't the worse thing in the world (and a 32bit immediate might make it worth it), but you start to hit weird explosions in gate count once you go much past that. Hence x86's splitting into essentially multiple front end banks in modern designs, and even then typically only has one decoder per bank that can decode everything, and even that takes multiple cycles for some instruction sequences, even just to discover the length.
The larger lengths in the RISC-V spec are more targeted towards bespoke stuff like GPGPU that's maxing out issuing a single instruction per instruction stream anyway. When you look at shader machine code, it's clear density was essentially an afterthought, but they love them some 64bit wide instructions. Which unsurprisingly is pretty much the same width of vertical microcode in archs that still do such a thing.
Maybe I'm misremembering. Or maybe the numbers I'm remembering took into account the fact that most compilers unroll more aggressively on x86 than on targets they consider to be "embedded" (another pet peeve of mine)
I stand by my assessment that the code density of rv64gc (and especially rv64g) is lower than it would be if they had actually put a focus on code density.
> A 16-32 decoder is pretty simple, a 16-32-48 isn't the worse thing in the world (and a 32bit immediate might make it worth it), but you start to hit weird explosions in gate count once you go much past that.
Not sure I would say 16-32 is simple, certainly massively simpler than x86. My point is that you have already paid the tax for going variable length, and 16-32-48 isn't that much more complex. And probably worth it for 32-bit immediate/offsets.
And maybe 16-32-48-64 is worth it... Hard to tell, but I wouldn't entirely rule it out without study. The advantage would either be immediates/offsets that are too big to fit in 48 bits. Or some kind of VLIW style scheme which actually packed three 20-bit instructions into aligned 64-bit packets. (Or other mixtures of sizes like 30-30, 30-15-15, 40-20, or 15-15-15; We are talking about a complete break from RISC-V. There is a thread somewhere on HN where we brainstorm something like this).
But beyond that, no point really. Just pointing out that RISC-V reserved the space.
Maybe I need to prototype the 64-bit aligned packets idea someday, at least far enough to get instruction density numbers.
It is, with a prefix encoding, you can reuse the RVC decode path 1-to-1 and get the 48/64-bit instruction starts with a simple bitshift (or simply handle the 48/64-bit instructions via the fusion path). This seems to be the encoding direction RISC-V is headed in.
Most MCUs are used for dead-simple solutions, like electric blankets and microwaves with segment displays or LEDs. Whether their interrupts are handled in 44 or 22 cycles doesn't really matter that much.
And RISC-V does have a link register, making returning much faster when the parameters for the interrupt can all fit in registers and no external memory access is needed, as is the case with most MCUs which put the stack in RAM. To fetch the return address an external memory access is always needed even if there are no parameters.
We already had the mystery meat CPU wars several decades ago. We know how to make sane ISAs now and should be past that.
But you'll practically be passed a device tree from SBI that will tell you.
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.
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.
Especially consider the possibility that a product manager decides to swap out the core for a different core to save 5¢ on the BOM. Does the product manager know to ask if the two cores follow the same RISC-V profile? Do the software programmers think to ask? How about communicating the change to all of the vendors or contractors providing you binary blobs? I don't know how likely it would be for a scenario like he author here describes, but it is definitely a plausible scenario.
Even if the core was supported just fine, all of the IO mux stuff is pretty much guaranteed to be different even with the same chip in a different package.
You're looking at explicit support for each chip.
That's how a sizeable chunk of software is written and shipped.
Runtime detection of CPU features is very much a thing, and is in fact used extensively in software you use or interact with every single day.
Just as a quick example, OpenSSL's approach for x86_64 is OPENSSL_ia32cap
https://docs.openssl.org/master/man3/OPENSSL_ia32cap/
This ensures (in theory, at least) that even if you're using your linux distribution's openssl library which is more generically targeted, you will get optimal/native runtime performance for your actual CPU.
In practice, this is not the case. The scenarios mentioned in the article involving binary blobs are pretty common, as well as other similar scenarios.
Really, I'm going to go out and say it bluntly: it is just completely freaking stupid to make an architecture where everything is optional but you have no way to query what's present. If you're going to go the optional-pieces route, you have to have a query mechanism of some sort. As the article explains, you cannot even trap instructions on RISC-V to figure out what your core supports, because bad instructions might belong to some other option. Complete. Idiocy.
Where are you getting the idea that RISC-V is dominant? As someone who works in this space, that doesn't jive with my experience or the sources I've seen.[1] 32-bit microcontrollers only recently achieved a majority market share for gosh sakes!
RISC-V is claiming that they have achieved 25% market share across selected segments, but they're still behind ARM (and x86).[2]
[1] https://www.grandviewresearch.com/industry-analysis/microcon...
[2] https://www.aestechno.com/en/risc-v-2026-arm-x86-market/
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.
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.
Do you really think Chinese manufacturers are going to buy ARM MCUs when their budget for a controller is less than 10 cents?
ARM has long ceded this market to RISC-V. It's mostly focusing on high-end application MCUs and AI now.
And lots of newer stuff is making use of standardized boards like Raspberry Pi Pico (RISC-V and ARM hybrid) or ESP32 (RISC-V too on some versions).
Because nobody will write software for 300 unique hardware variations of a platform that have inconsistent capabilities. Consistency is one of the reasons why x86-64 with extensions like like SSE, AVX2 etc is popular.
They didn't choose 8051 there for experience, but because it was a tiny core with a decent IPC they could license for a small part, then focus on the main cores. I wouldn't be surprised if they eventually switch to riscv there too.
Also, these 8051 cores tend to be extremely diverse. I don't think I've come across cores from different manufacturers that were actually compatible for real code. They all seem to want to handle accessing 16/32 bit memory differently, have different interrupt details, etc.
I really don't know anything about this space, but you just said that 8051 is dominant because it has one dominant architecture since the 70s. It has hundreds of manufacturers making identical parts.
As you say, software matters. If the Software can't run because of hundreds of extensions that can't be checked for, then you're going to pick a target that works, no? So in fact the ISA matters most: which ISA has the most software? Which ISA means my software runs on the most devices?
And yet you couldn't help yourself...
but you just said that 8051 is dominant
I said absolutely no such thing.
If the Software can't run because of hundreds of extensions
The software in the x86 world runs because there aren't hundreds of mutually incompatible extensions. I think the last time there was a major completely incompatible x86 ISA divergence was AMD "3DNow" vs other SIMD extensions. AFAIK the rest were "processor X got feature Y later than competitor Z".
Which ISA means my software runs on the most devices?
Easiest question evah: x86.
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.
I basically disagree with this. Not because this isn't the current state of things (it absolutely is), but because we're at a bit of an inflection point where mooore's law has proved itself to be an scurve, and we're very clearly well into the top half of it. From that, gate counts per core will also start to ossify, and that means the longer latency for getting an open core design off the ground initially will also start to make sense.
While RISC-V is quite optimised for gate count for small cores; In large wide OoO cores the variable length encoding really bulks out the decoders.
You basically have the same requirement as x86, where you have to attempt to decode a 32-bit instruction every 16-bits (because there is no alignment guarantee for 32-bit instructions), and then cancel out the invalid ones. It's not quite a bad as x86, you only need to look at two bits, but it still forms a long dependency chain, and probably requires at least one extra decode stage with complex routing to pick out all the valid instructions.
So not nothing, but very far from a deal breaker even for wide 8, 10, or even 12 wide cores.
I suspect a design with a full decoder every 16-bits might actually win on everything but gate count, mostly because it can deal with variable length instructions and variable number of μops per instruction in the same step. A decoder that doesn't output a μop because it was clobbered by a previous instruction, can be handled the same was as a decoder that didn't output a μop because of μop fusion.
Actually, that approach might actually eliminate the need for the extra pipeline stage (just at the cost of gates).
It's certainly not a deal breaker. But it's a valid criticism of the ISA.
And for better than aarch64 density, it seems to make a lot of sense.
I'm not even sure you have a point with regards to it being a valid criticism. Doubling the silicon area for instruction decoding probably costs nothing, because if you have a simple decompression stage, the maximum number of decoders is already doubled in the first place, because you're hypothetically encoding twice as many instructions to begin with. If you can double the decoders in the decompression stage, you can probably get rid of a separate decoding stage altogether and thereby reduce the cost to literally nothing.
Look, it might not be obvious but in university I once had to design an ASIP and then do the floor plan with Cadence and the area of the SRAM dwarfed everything to the point where my ASIP was a tiny vertical column in-between two SRAM chips. I personally was shocked by the fact that I struggled to even find my ASIP on the floor plan, because it was maybe ten standard cells wide in-between the SRAM blocks. Like, ridiculously tiny to the point where it is hard for me to even care about the area the ASIP took up.
YESSSS.
I've been pointing this out for years and years.
By the point that you're looking at the same propagation delay as a common 64 bit adder you're decoding 64 chunks of 16 bits per cycle. That's 128 bytes, or a 32-64 instructions wide decoder.
That is so much wider than anyone is making or contemplating — or that even makes sense given the size of basic blocks — that it's just a non-issue.
Insane take given all the things that run on Linux...
You do realize that Linux got basic SMP support 3 years after NT, and it was shaky for a while after? It still does not have reliable sleep-wake. And it only added native async file i/o in 2019, while NT has had it on the same hardware since 1993? So.. i'll expect an in-order core with an IPC south of 0.5 that cannot exit low power sleep 30% of the time in a decade or so.
Linux started about three years after NT did. And NT could only support 64 processors for a long time when Linux could support thousands.
> It still does not have reliable sleep-wake.
Neither does NT really. Both depend on ACPI for the systems you're talking about, and it's the platform interface that's ultimately fucked.
> And it only added native async file i/o in 2019, while NT has had it on the same hardware since 1993
And has beaten NT on IO throughput for decades, and even now windows ships with a linux kernel integration because running Linux on a hypervisor is far batter for filesystem ops than running those on NT.
And the new async I/O API was so good that NT adopted it wholesale and didn't even bother changing the name. https://learn.microsoft.com/en-us/windows/win32/api/ioringap...
> So.. i'll expect an in-order core with an IPC south of 0.5 that cannot exit low power sleep 30% of the time in a decade or so.
There are already open source OoO RISC-V cores.
But the point originally isn't to be some Linux fan boy (I've written a decent amount of NT kernel code, and have a lot of respect for NT and the things it did right). It's to point out how the upcoming changes inherent to how chips are made and the latencies between gate count targets will better support open collaboration. And once that's supported properly, open source has a tendency to kind of snowball.
I'm with Jim Keller when he says that in time the fastest CPUs will be RISC-V ones.
I would expect to see RISC-V Android phones (probably initially out of China, despite ARM China) within the next few years. They've been busy bees since RVA23 was ratified with a bunch of Chinese companies making changes to optimize AOSP for RVA23. I've also heard on the grapevine that NT already has a RISC-V port internally, but take that with whatever grain of salt you feel like. But Microsoft has already been contributing to the RISC-V specs (they contributed to Ztso for instance).
They did that with x86 and Arm half a decade before any announcement about a switch, not to mention a number of other ISAs that didn't make it to shipping (e.g. M88k) and probably ones that word has never leaked about. IA64, anyone?
They're too large and rich and risk-averse to *not* do it.
Well. May's law[0], which states that:
effectively counterbalances Moore's Law and, with continued technological process improvements and optimisations, the proverbial arm's race is likely to continue for a very, very long time – just a few days I was reading a wonderful article from 1998 on the state-of-the-art DEC Alpha 21264 CPU which mentioned the 21264 and POWER3 as the world's most complex CPU's each boasting 15+ million transistors and also mentioned the equally state-of-the-art 0.18 micron processes. The 3 old year M3 Max design, in comparison, supplies over 90 billion transistors to the mainstream consumer.Humans are resourceful, after all.
[0] https://en.wikipedia.org/wiki/David_May_(computer_scientist)...
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.
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.
If a compressed instruction could load or store a word to a word-scaled offset 0-3, relative to a register base address, that would be quite useful. It could be used for accesses to all structures four words or smaller.
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.
Specific choices for instruction encoding is less interesting, especially in the age of AI.
I was excited when I heard about the project just after it started. However, past experiences taught me to wait before getting excited about the new 'shiny thing'. I did it differently with RISCV. I waited. I am glad I did. It took a long time for actual silicon to appear. Also, the silicon today has all the facepalming special cases mentioned in the article. Its almost like those old soviet era cpus that had the list of bad instructions handwritten on the package.
Overall, RISCV was a minor spin on MIPS, but without really learning from other processors.
So why is everyone still pushing for it? It has the words 'open' on it. People pattern match on that marketing.
As part of that marketing, they also pushed this attitude from the project... 'RISC won'. I think Chester Lam said it best when he wrote his essay stating that RISC didn't win... OoO archs won. I couldn't articulate that nearly as well as he did. If you haven't read it, I recommend it.
So, yeah, here we are. Many people will follow the bandwagon, but they will find that RISCV will not make a significant difference.
I am glad we still have Arm (in all its many forms), x86, and others. (btw, despite my username, I don't think x86 is the best either :-)
Also, if you aren't trying to ship a product, you can experiment with ISAs on an fpga. Yes, fpgas are a lot slower, but they are also a lot more fun. Especially with the great work done to create open source toolchains. Heck, if you are really serious (slighly crazy), you can build your own chip. For the foreseeable future ASIC shuttles are available at prices under $10k. (again, you have to be a little crazy)
[1] Not because of often-called "risc like" microcode engine, but because the most complex addressing mode on x86 usually decodes two microinstructions, and decodes in single cycle. In comparison VAX needed separate pipeline for instruction decoding.
What a lovely euphemism.
Signed: someone slightly crazy.
The meme joke about standards is sadly relevant for riscv. =3
https://xkcd.com/927/
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.
Maybe Gentoo could tame that level of chaos... or people just buy ARM64 again knowing the software ecosystem already works. =3
https://en.wikipedia.org/wiki/Second-system_effect
Bookmarked, because I've needed the same.
The worst part of all this is that they really should have known better by now. In 1980 you could make these kinds of mistakes, because this was pretty new territory. In 2020, doing this just makes you stupid. Or ignorant. Or both.
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 no wonder Microsoft is pulling out of the game console market and handing it over to PC manufacturers to make the actual hardware.
They've definitely gone overboard on the optionality stuff though. I don't think it matters too much for the actual CPU design but it makes verification and writing portable software a huge pain. Profiles definitely help but still...
Oh also I feel like you could probably come up with an equally compelling list about any other ISA. It's not like the fact that something has flaws means it's bad.
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).
3. You are writing a kernel, with large amounts of inline assembly
4. You are writing a compiler, either offline or online
5. You are writing embeddable blobs that don't know what platform they will be running on.
6. You are designing a RISC-V core, and need to decide which extensions you should be supporting for your intended use-case.
I added an "misa but more bits" register to my core, using the bit assignment from the RISC-V C API, so at least until then I know what extensions each instance of my core implements. https://wren.wtf/hazard3/doc/#reg-h3.misa
Linux folks seem to have already put a lot of the mconfigptr info into the DT blob anyways.
You're allowed to not handle a majority of extant Linux-capable machines, but it seems like an awkward position.
1) power
2) performance
3) die area
SOME chip designs also care about a 4th:
4) die area.
NO design has the best of all...it is impossible since you have to trade 1 for another. The reason x86 has been dominate for so long is that is strikes a good balance across all areas, especially #4. A good balance is what you need for a good chip.
EDIT: oh and you can't beat the system I mentioned above. The laws of physics are the reason why.
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.
He forgot electronic cigarettes (vapes)
None of these things are remotely bad enough to make the downsides of using another ISA palatable.
Sad.