>>52
MIPS manual:
The NOP instruction is actually encoded as an all-zero instruction. MIPS processors special-case this encoding as performing no operation, and optimize execution of the instruction. In addition, SSNOP instruction, takes up one issue cycle on any processor, including super-scalar implementations of the architecture.
ALPHA reference manual:
Implementations are free to optimize these into no
action and zero execution cycles.
MIPS's dedicated NOP (SSNOP) is for filling coprocessor or FPU delay slots. Nearly all RISCs and some CISCs use NOP as a synonym for some other do-nothing instruction and then special-case it in the hardware since they know there is no other reason for a programmer to use that instruction.
The all-zero MIPS NOP is actually sll $0, $0, 0. PowerPC (ori r0,r0,0), ALPHA (LDQ_U R31,0(Rx) for "UNOP", BIS R31,R31,R31 for "NOP", and CPYS F31,F31,F31 for "FNOP"), SPARC (sethi 0,%g0), ARM (MOV r0,r0) and S/360 (BC 0, "branch never") are other architectures that do similar things as MIPS and x86 regarding NOPs.
RISC design includes "synthetic instructions" which are practical because of the fixed-length instructions. In something like 68k there is both CLR.L and MOVE.L because instructions are variable length. In RISCs, there's no point in making a separate CLR instruction because it would be the same size and speed as XORing the register with itself or loading immediate 0 and would just complicate decoding and waste opcode space.
With only a maximum of 64 opcodes, explicit compare, and no mention of any delay slots or coprocessors, I don't think a dedicated NOP would be necessary for this particular CPU. Even if there was an FPU with exposed pipeline, you could special-case OR R0, R0 for the no cycle NOP and use OR with any other registers for the one-cycle NOP, so there's still no need to waste opcodes for a dedicated NOP.