Is MOP.R.16 a NOP by default?
Unless redefined, it writes 0 to x[rd] rather than being defined as no operation; with rd=x0, x0 stays zero.
MOP.R.16
RISC-V MOP.R.16 Instruction Details
Instruction ManualI-typeZimop MOP.R.16: writes 0 to x[rd] unless redefined by another extension; may be redefined to read rs1 and write rd.
Instruction Syntax
mop.r.16 rd, rs1
Operand Breakdown
rd: the default semantics write 0 to x[rd]; with rd=x0 the architectural write is discarded and x0 remains 0.
rs1: an explicit register field in the recommended assembly syntax; the default Zimop definition does not read it and carries no syntactic dependency from rs1 to rd.
Bits 31..20 are a fixed MOP.R.n selector, not an assembly immediate and not a 12-bit signed value to sign-extend; only a future redefining extension may specify an rs1 read.
ZimopSystem & Privileged
Extension condition: RV32/RV64 with Zimop 1.0. The zero-write behavior below applies unless another extension redefines this encoding.
Instruction Encoding
31..20
fixed n selector
19..15
rs1
14..12
funct3
11..7
rd
6..0
opcode
MOP.R.16 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.
Format: Zimop MOP.R SYSTEM fields (n=16)
opcode: 1110011 (0x73)
funct3: 100 (0x4)
Fixed n selector (bits 31..20): 110000011100 (0xc1c)
Instruction Behavior
MOP.R.16 is a Zimop may-be-operation with recommended syntax mop.r.16 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.
Quick Understanding & Search Notes
MOP.R.16 belongs to Zimop 1.0. Unless redefined by another extension, it only writes 0 to x[rd]; with rd=x0, x0 stays zero.
MOP.R.n uses a 32-bit SYSTEM encoding; either rd or rs1 may name any x-register. Bits 31..20 are the fixed n selector, not an assembly immediate.
The default Zimop definition carries no syntactic rs1-to-rd dependency; a redefining extension may specify an rs1 read and impose that dependency.
Common Usage Scenarios
Zimop default zero write
Default Zimop behavior only: mop.r.16 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.
Extension redefinition
Default Zimop behavior only: mop.r.16 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.
Pre-Use Checklist
Syntax Check
- Confirm the assembly syntax has only rd and rs1; bits 31..20 are the fixed MOP.R.n selector, not an immediate.
- Confirm any x-register is valid for rd or rs1; the default definition does not read rs1 and carries no syntactic rs1-to-rd dependency.
Semantic Check
- Confirm that, unless another extension has redefined it, the instruction only writes 0 to x[rd]; with rd=x0, x0 remains 0.
- Do not assume a specific future redefining operation; standard software should execute this MOP only when deliberately targeting that redefining extension.
Pitfalls / Common Confusions
Unless redefined, MOP.R.n writes 0 to x[rd]; with rd=x0, x0 remains 0. C.MOP.n instead writes no register by default.
Default Zimop MOPs carry no syntactic dependency from rs1 to rd; a redefining extension may specify otherwise.
Do not confuse Zimop MOP.R.n with Zcmop C.MOP.n, which writes no register by default.
FAQ
Should ordinary software execute MOP.R.16?
No, unless the software deliberately targets an extension that redefines that MOP.