Is MOP.R.5 a pure no-op by default?
No. Unless redefined by another extension, mop.r.5 x5, x6 writes zero to x5 regardless of x6; x6 is unchanged. With rd=x0, x0 stays zero.
MOP.R.5 is a Zimop 1.0 may-be-operation; unless redefined, it writes zero to x[rd].
Extension condition: RV32/RV64, requiring Zimop 1.0. Zero-writing below applies only when another extension has not redefined the encoding; it does not guarantee execution without Zimop.
MOP.R.5 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.
MOP.R.5 has recommended syntax mop.r.5 rd, rs1; both operands accept x0–x31 and may overlap. 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 to read rs1 and change architectural effects. Standard software should execute it only when deliberately targeting an extension that redefines this MOP.
MOP.R.5 is a Zimop 1.0 may-be-operation; unless redefined, it writes zero to x[rd].
Default Zimop behavior only: mop.r.5 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.5 x5, x6 writes zero to x5 regardless of x6; x6 is unchanged. With rd=x0, x0 stays zero.
No. The syntax is mop.r.5 rd, rs1; bits 31..20 are fixed to 0x85d, an instruction selector rather than a signed immediate.