Is MOP.R.0 a NOP by default?
Unless redefined, it writes zero to x[rd], replacing the old value when rd is not x0. With rd=x0, the write is discarded and x0 remains zero.
MOP.R.0
RISC-V MOP.R.0 Instruction Details
Instruction ManualZimop MOP.R SYSTEM fieldsMOP.R.0 is a 32-bit Zimop 1.0 MOP that writes zero to x[rd] unless another extension redefines it.
Instruction Syntax
mop.r.0 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.0 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=0)
opcode: 1110011 (0x73)
funct3: 100 (0x4)
Fixed n selector (bits 31..20): 100000011100 (0x81c)
Instruction Behavior
MOP.R.0 is a Zimop may-be-operation with recommended syntax mop.r.0 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
For MOP.R.0, n=0 selects the encoding; it is not an assembly immediate. rd and rs1 can name any integer register, including x0. The default result is independent of rs1.
32-bit SYSTEM encoding: bits 31..20=100000011100 (0x81C), funct3=100, opcode=1110011; rs1 is in bits 19..15 and rd in bits 11..7.
Zimop 1.0 defines MOP.R.0 through MOP.R.31. The default writes zero to x[rd] with no syntactic dependency from rs1 to rd; a redefinition may specify an rs1 read.
With rd=x0, x0 remains zero. rd=rs1 is also legal and still writes zero under the default definition.
Common Usage Scenarios
Extension Compatibility
Default Zimop behavior only: mop.r.0 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
The default is not a true no-register-write NOP; MOP.R.n writes zero to rd 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.0?
No, unless the software deliberately targets an extension that redefines that MOP.