Is MOP.R.2 a NOP by default?
Unless redefined, it writes zero to x[rd] rather than preserving the destination. If rd=x0, x0 remains zero.
MOP.R.2 is a 32-bit Zimop 1.0 MOP that writes zero to x[rd] unless another extension redefines it.
MOP.R.2 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.2 is a Zimop may-be-operation with recommended syntax mop.r.2 rd, rs1. If no other extension redefines the encoding, the official default behavior writes 0 to x[rd]. The encoding space allows future extensions to define it as reading x[rs1] and writing x[rd]. Standard software should not execute a MOP unless deliberately targeting an extension that redefines it.
MOP.R.2 has two explicit integer-register fields. Unless redefined, x[rd] receives zero regardless of the old x[rs1] value; rd=x0 leaves the zero register at zero.
Default Zimop behavior only: mop.r.2 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.
Default Zimop behavior only: mop.r.2 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.
Unless redefined, it writes zero to x[rd] rather than preserving the destination. If rd=x0, x0 remains zero.
No, unless the software deliberately targets an extension that redefines that MOP.