FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
66% Positive
Analyzed from 8510 words in the discussion.
Trending Topics
#risc#instruction#isa#arm#don#better#code#more#instructions#same
Discussion (225 Comments)Read Original on HackerNews
Excellent and well written description of the RISC-V ISA.
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...
Why?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.