Is MOP.R.28 a pure no-op by default?
No. Unless redefined by another extension, mop.r.28 x5, x6 writes zero to x5 regardless of x6; x6 is unchanged. With rd=x0, x0 stays zero.
MOP.R.28
RISC-V MOP.R.28 Instruction Details
Instruction ManualSYSTEM (Zimop MOP.R)MOP.R.28 is a Zimop 1.0 may-be-operation; unless redefined by another extension, it writes zero to x[rd].
Instruction Syntax
mop.r.28 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 fixed to 110011011100, not an assembly immediate. With Zicfiss active, some register combinations are already SSPOPCHK or SSRDP; default zero-writing does not describe those redefined effects.
ZimopSystem & Privileged
Extension condition: RV32/RV64, requiring Zimop 1.0. The zero-writing behavior below applies only to encodings not redefined by another extension; it does not guarantee execution on processors without Zimop. When Zicfiss is implemented and active for the current mode, rd=x0 with rs1=x1/x5 selects SSPOPCHK, while rs1=x0 with rd≠x0 selects SSRDP. Remaining encodings follow Zimop unless otherwise redefined. These subsets revert to Zimop behavior when Zicfiss is absent or inactive.
Instruction Encoding
31..20
fixed n selector
19..15
rs1
14..12
funct3
11..7
rd
6..0
opcode
MOP.R.28 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=28)
opcode: 1110011 (0x73)
funct3: 100 (0x4)
Fixed n selector (bits 31..20): 110011011100 (0xcdc)
Instruction Behavior
The recommended syntax is mop.r.28 rd, rs1. Either operand may name any integer register x0–x31, including the same register. Default Zimop behavior only writes zero to x[rd], without reading x[rs1] or carrying an rs1-to-rd syntactic dependency; rd=x0 leaves x0 at zero. Another extension may redefine the encoding with an rs1 read or different architectural effects. Standard software should execute a MOP only when deliberately targeting an extension that redefines it.
Quick Understanding & Search Notes
MOP.R.28 is a Zimop 1.0 may-be-operation; unless redefined by another extension, it writes zero to x[rd].
Zimop 1.0 defines 32 MOP.R.n instructions (n=0–31); MOP.R.28 is the 32-bit instruction numbered 28.
Bits 31..20 are fixed to 110011011100 (0xcdc); bits 19..15 hold rs1, 14..12 hold funct3=100, 11..7 hold rd, and 6..0 hold SYSTEM opcode=1110011.
The recommended syntax has only two integer register operands, rd and rs1, with no immediate; both accept x0–x31 and may overlap.
Unless redefined, the result is zero regardless of the old rs1 value; rd=x0 leaves the hardwired zero register unchanged.
When Zicfiss is implemented and active for the current mode, rd=x0 with rs1=x1/x5 selects SSPOPCHK, while rs1=x0 with rd≠x0 selects SSRDP. Remaining encodings follow Zimop unless otherwise redefined. These subsets revert to Zimop behavior when Zicfiss is absent or inactive.
The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture, Version 20260120 — Chapter 10, “Zimop” Extension for May-Be-Operations, Version 1.0The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture, Version 20260120 — §2.1 and §4.1, integer register stateThe RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture, Version 20260120 — §34.2.1, §34.2.5–§34.2.6, Zicfiss redefinitions
Common Usage Scenarios
Zimop extension compatibility
Default Zimop behavior only: mop.r.28 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
Default zero-writing differs from a no-register-write NOP or HINT; rd=x0 does not justify ignoring the effects of a redefining extension.
There is no immediate operand. The mnemonic suffix selects fixed encoding bits, not a runtime numeric input.
Default behavior neither reads rs1 nor carries an rs1-to-rd syntactic dependency; a redefining extension may specify otherwise.
Standard software should execute this MOP only when deliberately targeting an extension that redefines it.
FAQ
Does MOP.R.28 have an immediate operand?
No. The syntax is mop.r.28 rd, rs1; bits 31..20 are fixed to 0xcdc, an instruction selector rather than a signed immediate.
Do all MOP.R.28 encodings always write zero?
When Zicfiss is implemented and active for the current mode, rd=x0 with rs1=x1/x5 selects SSPOPCHK, while rs1=x0 with rd≠x0 selects SSRDP. Remaining encodings follow Zimop unless otherwise redefined. These subsets revert to Zimop behavior when Zicfiss is absent or inactive.