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.

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.

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.

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

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.

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

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.

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.

> 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 … 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 happened to the Rivos accelerator cores?

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

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.

Sad.