I don't know if MIPS is the same, but I worked on an other architecture where NOP is 0x0, and it had an interesting effect. If you called an uninitialized function pointer, and it happened to point into zero:ed out memory, the CPU would execute NOPs for a good while until it hit something else. If that something else was code, it would start executing some function from the start, but with garbage arguments. It would often get quite far in and several functions calls down before something crashed. Made for fun stack traces and interesting debugging :-)
Seems like a better design choice would be to have instruction 0x0 throw some kind of page fault violation or other exception the OS can catch then.
Shades of the 6502, where 0 was BRK
It is and on RISC-V 0 (16-bit bits and 32-bit) are an illegal instruction. Jumping to zeroed page is obviously a bug so this is the correct behavior.
AVR does this. I can attest to the “interesting” debugging...
nanoMIPS (the last compressed MIPS ISA that sadly never made it across the whole product line) re-encoded nop(32) for much the same reason.
RISC-V deliberately made sure both all 0s and all 1s are forever illegal instructions, in all instruction lengths.
Wasm too. Bytecode 0 is "unreachable" and executing it produces a trap.
Specifically to avoid infinite loops?
To make hitting uninitialised RAM or Flash or OTP (or others) stop the program immediately.