Well, maybe. I feel like he still has a point with array indexing and JAL.

Stand-alone array indexing, not in a loop, is quite rare and seldom affects code speed. When it is in a loop, the calculation is usually strength-reduced to a bump of a pointer by a constant, so things such as scaled register indexing aren't actually used a lot.

It is true that there is a range of offsets between ±1 MB and ±128 MB in which arm64 can use a single BL instruction while RISC-V's JAL won't reach. Both need two instructions (8 bytes) for a ±2 GB subroutine call. You'd have to analyse program traces to find out how important this it in practice.

I haven't done that study myself, but I expect it would be a losing thing to bet that one of the authors (and his students / colleagues) of the famous "Computer Architecture: A Quantitative Approach" textbook didn't think to do this while making ISA design tradeoffs.

RISC-V does get genuine extra utility from being able to use other registers as the link register e.g. using the `-msave-restore` compiler flag to call runtime functions to save and restore registers instead of having load/store multiple, and being able to call that function before saving the Link Register.

I mean, that goes for the array indexing thing too, and all the other criticisms erincandescent makes. It's a very easy thing to say that constants and offsets should always be bigger, better, instruction sequences shorter but you then have to ask what else should be left out to make room, especially in an ISA with fixed-length instructions.