RISC-V: They Should Have Known Better

This whole thread makes me super depressed. People complaining about being ignored or booted out from a community and blaming it on that community's technical incompetence or NIMBYism for their social rejection. No self-reflection about why it might be the case that others got tired of (re)explaining things to them.

They did actually implement the system on an FPGA, but only once. A significant amount of the RISC-V architecture is informed by the superscalar, in-order design of boom.

Store Register with Offset is egregiously painful on a small, in-order system as you need a full extra pipeline phase solely for this instruction

Be as good as or better than an M0?

Could you explain the store issue a bit? As far as I can tell, M0 and RISCV are identical here?

M0:

STR, STRB and STRH instructions store the word, least-significant byte or lower halfword contained in the single register specified by Rt in to memory. The memory address to load from or store to is the sum of the value in the register specified by either Rn or SP and the immediate value imm.

RISCV (is there really no convenient web index of instructions? TT):

The effective address is obtained by adding register rs1 to the sign-extended 12-bit offset. Loads copy a value from memory to register rd. Stores copy the value in register rs2 to memory.

PowerPC and Alpha are not in the group of "the popular architectures".

They did implement on FPGA, but that’s part of the problem. They had an FPGA implementation and an immature GCC port and used this as the input to a lot of decisions. For example, the article complains about the immmediates scattered all over the place. This was done so that the source operands were known prior to decode, which let you do register fetch before decode. And that is really nice for small in-order cores.

It stops being as useful when you start having floating-point instructions because you know which register to fetch but not which register file to fetch it from.

For superscalar chips, you want to do this post decode because you don’t want false positives in keeping rename registers alive: that will hurt performance more than any decode speedup possibly could.

Even by the time you have dual issue, this property isn’t very useful. But they overfitted for the simple in-order core. All you’re left with is overhead in routing from pulling bits from different parts and running them together. This isn’t an enormous overhead and is normally drowned out by something else.

This also shows up in the C extension. It’s designed so that a simple core can expand every 16-bit instruction to a 32-bit instruction. That lets you add it in the decode stage without any modifications to later stages in the pipeline. And, yes, that does help. In simple, in-order cores.

But for big out-of-order cores, the thing that matters most is the amount of work done per instruction. You have a lot of fixed overheads in fetch, decode, instruction scheduling, register rename, and so on that you want to amortise those costs over larger amounts of work. Rich addressing modes are the obvious win here because doing a bit of arithmetic in a load-store pipeline is basically free, doing two instructions means you calculate the address twice. When this was pointed out early on in RISC-V, Krste kept asserting that instruction fusion (decoding two or more instructions as something that you execute as one) would solve all if those problems. This was never true: instruction fusion is hard, is even harder when trying to fuse instructions across fetch granules, and it means you’ve defined a per-implementation variable-length instruction encoding that compilers have to know about.

The article overstates the cost of decoding variable-length ISAs. I worked on an ISA designed for server cores that used a variable-length encoding and the decoder didn’t show up as a problem in any of the evaluation. And it let us put a load of things in 48-bit instructions, so the 16-bit instruction subset covered well over 50% of dynamic instruction counts. Instructions for system calls and instructions that are usable only in privileged modes were all 48 or 64 bits, so they didn’t eat any of the shorter encoding space.

It's been a while, but: 6502 was only easy because of its tiny instruction set and tiny set of registers; it was pretty frustrating for me. Z80 was actually elegant. (I had a Z80 on a card in an Apple ][+ back in the 80s.)

And Motorola is the only company who consistently designed nice ISAs. Unfortunately, I never really got to use theirs.

I am working on being more polite with my words, but this article is a real struggle given the author's attitude. RISC-V was designed by academics and industry veterans with decades of experience. They certainly knew better than the OP.

Complaining about modularity is the thing that makes it so RISC-V doesn't carve mistakes in stone forever, like the proprietary ISAs do. While standard profiles must go through a committee of actual implementers, the modularity OP is complaining about makes it so anyone who has a need for a different set of instructions (including proprietary ones) can do so. Qualcomm did this while developing some silicon and proposed changes. The committee thinks it's a good idea, so those changes will probably go into a future version.

The OP is free to make their own profile and very much encouraged to try and make it a standard! Instead they argue that the only reason the inventors of RISC didn't adopt their preferred open ISA is NIMBYism. This rant is like an undergrad getting frustrated with their homework and calling the professor and authors of the textbook stupid.

While I'm saddened to see it getting voted up so much on Lobsters and elsewhere, the community is pretty burnt out re-explaining this stuff to the non-curious. I'll update this comment if we get around to creating a FAQ for this type of content on the r/riscv wiki.

The blog preempts this, but it is interesting that about half (but certainly no more) of the issues come from RISC-V not effectively supporting binary reuse across different processors. This definitely takes RISC-V out of contention for desktop computing—where binaries are the de-facto distribution format for software—without adding other standards on top. But it does feel like a defensible choice for a lot of use cases, especially if requiring a recompile can allow you to use simpler and more efficient processors.

I appreciate the point about openness. An open spec does very little to make implementations open, unfortunately. If mainstream desktop RISC-V CPUs ever come, there's a 90% chance that they will run closed source UEFI firmware, have hardware that requires executing ACPI bytecode blobs, have undocumented integrated management processors, etc...