RISC-V: They Should Have Known Better

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.

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.

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

This is not the only reason to use a microcontroller or 75% of microcontroller vendor (e.g. STM) offerings would have no customers. Not everyone has custom IP that does all the work either, that’s actually fairly rare. It’s odd to pigeonhole microcontrollers like this just to go on a fairly lengthy rant about interrupt latency as if that somehow makes RISC-V unsuitable to what is an incredibly diverse application space. Maybe the rest of their post has better arguments, but I’m not impressed enough by the first one to keep reading.

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.

We are using RISC-V for AI accelerators to great success

https://ai.meta.com/blog/meta-mtia-scale-ai-chips-for-billio...

RISC-V was a great choice due to being so customizable and extensible.

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.

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

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.

Near the end of the essay, the author mentions that the folks at Berkeley considered OpenRISC.

Would that have been a better path do go down, to throw a bunch of work, money, and R&D after, or is there anything inherently bad about that design besides delay slots?

I kinda feel that even the smartest people will build great things on crumbling foundations as long as those foundations are available. I'm thinking of NASA embracing RISC-V or anyone who decided to write secure-by-design software in C.

*edit - rephrased question for clarity

It's basically MIPS all over again

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.

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.

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.

Yet it's royalty-free and good enough for Espressif (maker of ESP32) to move exclusively to the RISC V open-source instruction set architecture [1].

"Good enough ISA plus zero licensing cost" beats "perfect ISA plus royalties" in the embedded space.

Also, let's not forget that the reason the world is built on the von Neumann architecture is that it was made available for free.

[1] - https://www.eenewseurope.com/en/espressif-moves-exclusively-...

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.

Random minor-ish notes:

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

Just noting, even if instructions were 100000000000000 bits long, reserving a single bit for 16-bit encoding would waste 50% of the instruction space.

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

I can definitely see his argument, although I still do believe RISC-V did a lot of things better than x86...

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.

Always good to see stuff from Dmitry; his presentation (Linux/4004) at last year’s Teardown was awesome.

Is there a RISC-VI in the works where they try to learn from the RISC-V mistakes to make improvements?

100% agree with dmitrygr.

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)

> 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 amused that the story doesn't even mention the 4k pages - way too small for anything but embedded systems today.

MIPS or PowerPC is also free. We can use them too.

So it's mostly the "Optionality". Like USB. And yet USB is everywhere...

RVA23 hardware is available (e.g. SpacemiT K3)

Refreshing style of writing. I know nothing about ISAs, but the rant was so fun

This feels like Andy Tennenbaum's LINUX is OBSOLETE post from 30 years ago.

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

> So what does it even mean to comply with the spec then, if everything is optional?

Similarly, I kept saying it for long that a file/wire format's usefulness is not in what it supports, but in what it forbids. A binary file supports any type of data, but it's not useful.

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.

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.

This guy is weird: there is no perfect ISA, only compromises and tradeoffs. He is looking for _his_ perfect. Won't happen, unless lucky, namely your perfect aligns with RISC-V tradeoffs. There are also sweet spots, and I am writting RISC-V assembly almost every day and that "hits" them often. I currently use at 99.99% the core ISA (I have a few muls and divs here and there). I don't even use the bit manipulation extension...

There are millions of RISC-V chips out there. Performant microarchitectures are getting there, but the access to the latest silicon process is gated by the other ones, hogging production capacity (and they probably don't want RISC-V to "get there"...).

And most of all, hardware manufacturer/designers won't have a lawyer ringing at their door: this is so much critical, this will make them tolerate a lot of RISC-V tradeoff choices they dislike.

And ofc, big mistakes WILL BE MADE AND WILL HURT BAD. Expecting anything else is thinking like a teenager.

It seems the current biggest mistake is the compressed instruction extension. It seems the complexity it adds for high performance is not worth it (arm removes the thumb instructions for reasons). I have suspicions on some microarchitectures designed around the compressed instructions (16bits) having a negative performance impact on core ISA 32bits instructions (and many compiler optimizations are friendly to the way compressed instructions are, namely the destination register is one of the source register, that due to the legacy x86_64). BTW, Intel APX something, is basically RISC-V for x86_64.......

Another aspect people tend to forget while dealing with RISC-V, many of those design choices were made for the simplest way to implement performant CPU microarchitectures. Some say thats why on 'out-of-order' CPUs, you don't want a status flag register (there is none in RISC-V).

+++

Excellent and well written description of the RISC-V ISA.

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.

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

He forgot electronic cigarettes (vapes)

I wonder if they will be inviting him to the next RISC-V design committee meeting.

If only ISAs weren't protected (or protectable) by patents.