What I'm hearing in this post is "Where RISC-V uses a smaller field size for something than ARM64 they have under-provisioned and will need extra instructions,

What I'm hearing in this post is "Where RISC-V uses a smaller field size for something than ARM64 they have under-provisioned and will need extra instructions, and where RISC-V uses a larger field size for something than ARM64 it will never be used and is wasted". In other words, ARM's architects chose every parameter correctly, and RISC-V's chose every parameter badly. It might be true, but you kind of have to prove it, not just assert it. Take the J/JAL vs B/BL range for example. It's not just embedded. Look through your Linux distro's binaries and you'll find very few with TEXT size over 2 MB. One of the few on my (x86_64, but it doesn't really matter) system is /opt/google/chrome/chrome with 159,885,517 bytes. That exceeds ARM64's single-instruction BL range, as well as RISC-V's. A quick analysis shows that of the 373500 callq instructions in the binary, statically 55.53% fall within the RISC-V single-instruction range, 100% fall within the ARM64 range. Dynamically I don't know, but I suspect the percentage that fall in the RISC-V range would be a lot higher. Anyway .. code size. The extra AUIPC instructions needed in the RISC-V program will make it around 648 KB or 0.4% larger than the ARM64 program. That's a pretty far cry from "I would estimate this one issue alone will result in a ~5-10% code size increase" you state. I mean -- that's a factor of 12x to 25x different than you state. But wait there's more. One reason that RISC-V JAL offsets are limited is that 2 bits out of 32 are taken up by indicating whether the current instruction is 4 bytes or 2 bytes in size. So that's a waste right? It would be if you didn't use it. But RISC-V does use it. In a typical RISC-V program, around 50% to 60% of all instructions use a 2 byte opcode, giving a 25% to 30% reduction in code size. On the same 152 MB program (Chrome) where not having long JAL offsets costs 0.6 MB of code size, the C extension will probably save around 40 to 45 MB of code size. That seems like a pretty good trade to me. What will the speed effect of those extra AUIPC instructions be? I don't know. I'd have to instrument Chrome and run it at a fraction of normal speed to find out. That's definitely something that should be done before making a pronouncement that one ISA is definitely better and the other one made all the wrong trade-offs. However, my experience of analyzing smaller programs is that the dynamic penalty (execution speed) is typically much less than the static penalty (code size). At a wild guess, I'd go with four times less, or 0.1%. That's in the noise. Might a RISC-V core be enough simpler than a comparable ARM64 core to clock 0.1% faster? Could well be. Might it be enough simpler to be 0.1% smaller and thus cost 0.1% less in die space -- or allow you to put 0.1% more cores on the same chip? Could well be. Even the detractors don't argue that RISC-V isn't simpler. "It's too simple" they say, takes purity and orthogonality too far. Maybe, but you need to prove it, not just assert it.