> some of the complex load/store ops, which are usually cracked

Ah, cracking. Another thing the RISC-V ISA will try to avoid at all costs.

> I don't think they would've added 3r1w if it wasn't for the complex load/stores.

Agreed. The complex load/store addressing is one of the fundamental parts of the original ARM design, and IMO the only one that really survived into AArch64 unscathed.

It actually needs to be 3r2w so that it can writeback both the updated base register and memory value for indexed loads.

And if you already need 3r2w (or to emulate it via cracking), might as well add other instructions to take advantage of it.

> I think it's a fine way to design an ISA

Really depends on what the design criteria are. If the goal is to create a "better MIPS" or "Easy to implement ISA, great for education" or "Optimised for low-transistor classic-RISC pipelines", then avoiding flags is a great idea.

And a good idea to avoid cracking, it just adds complexity and pushes you away from that "RISC purity". TBH, I'm a little surprised they got rid of branch delay slots, but I guess they really confuse people writing assembly (or compilers).

In many ways RISC-V is a great ISA, the extendability and openness is unparalleled and it does actually deliver on scaling all the way from ultra-low transistor designs, all the way up to high-performance out-of-order cores.

But if the design criteria is "An Open ISA optimised for the modern era", then I think RISC-V falls short. And the choice to avoid flags is one of the many minor issues that add up to making RISC-V sub-optimal for higher-end μarches.