Is MOP.R.14 a NOP by default?
Not a pure no-op. It writes zero to rd by default.
MOP.R.14
RISC-V MOP.R.14 Instruction Details
Instruction ManualI-typeZimop MOP.R.14; by default writes zero to rd and may be redefined to read rs1 and write rd.
Instruction Syntax
mop.r.14 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
Instruction Encoding
31..20
fixed n selector
19..15
rs1
14..12
funct3
11..7
rd
6..0
opcode
MOP-R-14 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=14)
opcode: 1110011 (0x73)
funct3: 100 (0x4)
Fixed n selector (bits 31..20): 100011011110 (0x8de)
Instruction Behavior
MOP.R.14 is a Zimop may-be-operation with recommended syntax mop.r.14 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.14 is a Zimop compatible encoding reserved for future extensions; when not redefined, its visible result is rd receiving zero.
The official rule places MOP.R.n encodings in the SYSTEM major opcode.
MOP.R.n allows a future extension to read rs1 and write rd, but by default it does not read rs1.
Common Usage Scenarios
System & Privileged
Understand this scenario with real code like «mop.r.14 t0, t1».
Extension Compatibility
Understand this scenario with real code like «mop.r.14 t0, t1».
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.14?
No, unless the software deliberately targets an extension that redefines that MOP.