The ability to write or design reliable compilers/debuggers that people will use in the real world, and estimations of "hardware complexity", has very little to

The ability to write or design reliable compilers/debuggers that people will use in the real world, and estimations of "hardware complexity", has very little to do with how difficult it is to emit object code for some ISA, I'm afraid to tell you. RISC is a meaningless term today to describe design complexity. People see 'cmov' in x86 or the boot process or variable-length instructions or whatever, and think, "wow, how horribly complex this all is, it must be a huge design problem, and it's probably because of the instruction" -- but if they see some modern ARM machine do superscalar OoO execution in order to execute an instruction over multiple cycles and the compiler scheduled instructions taking that particular latency/throughput into account so it could generate optimal code for that uarch -- it's like, wow, this is all so simple, it must make everything so much easier. It doesn't, but it's worth asking what does the debate even mean at that point? All the actual complexity is elsewhere, and is (mostly) independent of the ISA. Side note, but I have RISC-V hardware on my desk and one of the errata for this particular silicon is "the MMU may not catch and deliver all memory access violations correctly" -- meaning you just don't have memory protection sometimes, in some cases, on some days with some shirt colors! I'm pretty sure the ISA doesn't mandate that, and I'm also pretty sure it didn't come from the instruction decoder. Luckily, in this case, programmers have repeatedly proven they are extremely reliable at handling and estimating issues of memory safety (reliably bad at it).