Is MOP.R.30 a pure no-op by default?
No. Unless redefined by another extension, mop.r.30 x5, x6 writes zero to x5 regardless of x6; x6 is unchanged. With rd=x0, x0 stays zero.
MOP.R.30 is a Zimop 1.0 may-be-operation; unless redefined by another extension, it writes zero to x[rd].
Extension condition: RV32/RV64, requiring Zimop 1.0. The zero-writing behavior below applies only to encodings not redefined by another extension; it does not guarantee execution on processors without Zimop.
MOP.R.30 uses opcode 1110011 (0x73), funct3 100. MOP.R.n uses SYSTEM fields: bits 31..20 are the fixed n selector, rs1 and rd are explicit register fields, funct3=100, and opcode=SYSTEM. The default definition writes only 0 to x[rd]; rs1 is not a default read source.
The recommended syntax is mop.r.30 rd, rs1. Either operand may name any integer register x0–x31, including the same register. Default Zimop behavior only writes zero to x[rd], without reading x[rs1] or carrying an rs1-to-rd syntactic dependency; rd=x0 leaves x0 at zero. Another extension may redefine the encoding with an rs1 read or different architectural effects. Standard software should execute a MOP only when deliberately targeting an extension that redefines it.
MOP.R.30 is a Zimop 1.0 may-be-operation; unless redefined by another extension, it writes zero to x[rd].
Default Zimop behavior only: mop.r.30 x5, x6 sets x5 to zero regardless of the old x6 value; x6 is unchanged. Standard software should execute it only when deliberately targeting an extension that redefines this MOP.
No. Unless redefined by another extension, mop.r.30 x5, x6 writes zero to x5 regardless of x6; x6 is unchanged. With rd=x0, x0 stays zero.
No. The syntax is mop.r.30 rd, rs1; bits 31..20 are fixed to 0xcde, an instruction selector rather than a signed immediate.