MOP.R.20

RISC-V MOP.R.20 Instruction Details

Instruction ManualZimop MOP.R SYSTEM fields

MOP.R.20 is a 32-bit Zimop 1.0 MOP that writes zero to x[rd] unless another extension redefines it.

Instruction Syntax

mop.r.20 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.20 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=20)
opcode: 1110011 (0x73)
funct3: 100 (0x4)
Fixed n selector (bits 31..20): 110001011100 (0xc5c)

Instruction Behavior

MOP.R.20 is a Zimop may-be-operation with recommended syntax mop.r.20 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.20 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.

Zimop 1.0 defines MOP.R.0 through MOP.R.31. The default writes zero to x[rd] without a syntactic rs1-to-rd dependency; a redefining extension may specify an rs1 read.
RV32/RV64 use the same 32-bit SYSTEM encoding: bits 31..20 for MOP.R.20 are fixed to 0xc5c, funct3=100, opcode=1110011. The selector is not an immediate.
Recommended syntax: mop.r.20 rd, rs1. In the RV32I/RV64I register model, either field may select x0 through x31, and the fields may select the same register.
Standard software should execute this MOP only when deliberately targeting an extension that redefines it; the default does not describe the redefining operation.

Common Usage Scenarios

System & Privileged

Default Zimop behavior only: mop.r.20 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 Compatibility

Default Zimop behavior only: mop.r.20 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, the default writes zero to x[rd] rather than preserving the destination; with rd=x0, x0 remains zero.
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

Is MOP.R.20 a NOP by default?

Unless redefined, it writes zero to x[rd] rather than preserving the destination. If rd=x0, x0 remains zero.

Should ordinary software execute MOP.R.20?

No, unless the software deliberately targets an extension that redefines that MOP.