RISC-V: They Should Have Known Better

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.

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?

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.

The underlying truth seems to be that a “clean” ISA doesn’t by nature make the beer taste better, and many of the warts probably have a reason for existing.

64-bit instructions with 4 bits indicating instruction formats (60-bit, two 40+20-bit variants, 30+30-bit, 20+20+20-bit, three 30+15+15-bit variants, and 15+15+15+15-bit). Have each larger instruction type be a strict superset of the smaller instructions, but with larger immediates, more registers, and maybe additional instruction formats (eg, for SIMD).

Something like that would be even easier to decode (converting short instructions to long is simply a bit of wiring). Instruction density should increase due to 20-bit instruction type. Having properly-aligned instructions would help with fetching performance. Larger instructions means you can jump 4x further with the same immediate and 16-bit offsets. No need to have some of the V extension workarounds (from not wanting to add 48-bit instructions).

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.

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

Where do people get ideas like this from? Just nonsense.

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.

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.

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.

SSE has inconsistencies like SSE4.x vs SSE4a. AVX is an even more mixed bag. There are some 19 AVX-512 extensions and ZERO chips support all of them.

The situation is so bad that AMD and Intel got together to make AVX10 to unify everything. That seemed great, but Intel now has AVX 10.1 and 10.2 in addition to the base set, so there we go again...

x86 is a massive battleground with tons of competing extensions like FMA3 vs FMA4 (why did FMA3 win???) and in cases where one of the competing variants didn't win, we get something like virtualization extensions being completely different between Intel and AMD. There's also the rash of security extensions that have gone through various support and dropped support (not to mention using some of this stuff for market segmentation and further fragmenting the ecosystem).

x86 is anything but consistent if you look into its history (or even it's present).

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.

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.

  > fired half of them

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

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.

> 1. Supported in mainline LLVM and GCC.

Which pretty well encapsulates the ecosystem requirements.

Of course not because that's impossible to prove.

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.

There are lots of somewhat successful yet little-known Chinese companies with their own proprietary architectures and the toolchains to match, so I don't think it's that clear-cut. (That said, most if not all of them are somewhat MIPS/RISC-V-ish anyway...)

I do think 8051 is better when you don't need 32 or even 16 bits. Even 4-bit MCUs are still around in ultra-low-cost ultra-high-volume products, which is to say RISC-V is, as you said, just a different flavour of MIPS with very similar tradeoffs.

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.

To the extent that Raspberry Pi shipped a microcontroller that can literally be either RISC-V or ARM (indeed, one of each at the same time I think?)

RISC-V, it seems to me, lives in that cognitive space occupied by things like: open source, open weights, C, HTML, ethernet, Greggs sausage rolls and VHS.

Far from optimal, obviously flawed, and could change human society for the better. Ubiquity is inevitable.

Of course! Most people in the computing world work way higher up the ladder of abstraction. I suspect a small minority of working software engineers know what an ISA even is.

I did some contract work in web development for a time. It is staggering how few people understand how the javascript they write gets executed on the machine. People don't understand pointers, or virtual machines, or in many cases how JS bundlers work, despite using them daily.

In some ways, this is a sign that our abstraction layers have been a great success! People can program for the virtual javascript machine, without needing to understand how the actual machine works, or how it emulates javascript. Is this the future we wanted? I'm not sure. But it's here.

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.

RISC-V is mainly a way to avoid IP conflicts, not as a technical breakthrough. MIPS itself was a boring (this is good) implementation of the original RISC papers, but they asserted a bunch of things legally which eventually, along with the legal work of Arm meant that ISAs were effectively owned by their parent corporations.

I'd assert that much like 3rd parties being able to make replacement car parts, that we should be able to make ISA compatible chips. But here we are, RISC-V needs to exist and does, but for legal reasons, not technical ones.

*edit, I forgot to refresh before posting, what bjornnn said.

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 want the iteration of the product that is in its 2nd or 3rd official iteration. Where you have a lot of learning done and battle tested. Preferably without the backward compatibility to create something truly beautiful. Would it be perfect? Of course not. But it will be Great.

I so wish ARM had some counter offering. They might as well give away their their low end design for free.

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.

So not nothing, but very far from a deal breaker even for wide 8, 10, or even 12 wide cores.

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.

RV actually allows for that. But not dictating that registers get pushed to the stack, flexibility in how you manage them opens up. So for RV, and some other architectures, you have to mark the function an IRQ and the compiler will know how to figure that out.

Another gotcha is that for AXI and other burst interfaces, the hardware being able to say "I'm going to send you X words" is dramatically better for latency than each one being a single transaction. So if your stack is in a location that requires multi-cycle memory access times, this balloons in timing cost.

Sadly this is a very hard topic to condense into a few sentences. Maybe if I wrote an article on it with graphics it would help. Unsure

Take for example a post increment load, which does a=mem[b++], notice how this writes to two registers. Handeling two writes (up to 4) would explode the stage after decode (rename). So high performance arm implementations generate two uops for this. But since the number of decoders is fixed and the number of rename slots as well, you now have alnost the same problem as in RISC-V with compressed instructions: the nth input to the rename stage can come from a variaty of outputs of the decode stage, so you need a large shuffle network, and propagate the uop counts from start to end.

Cracking is a lot cheaper, if you can do it later in the pipeline. E.g. the cheapest is if you can simply "replay" the instruction. That is, instead of removing the entry from the issue queue, when it starts executing, you decrement a counter and keep the entry to do something else next. But as I mentioned that doesn't really work with multiple write back.

This allows it to split complex instructions into multiple operations instead of having dedicated hardware for it.

High performance cores can also do the opposite trick of "fusing" two instructions into a single uOp: The usual example is compare-and-branch

And what if that blob has instructions your new core just doesn't implement? This problem has nothing to do with overlap.

EDIT: Leaving that Å in. For some reason, iOS on iPad is obsessed with autocorrecting "A" to "Å" even when using the English keyboard. It's driving me nuts.