1. "Zimop" May-Be-Operations Extension, Version 0.1

This chapter defines the "Zimop" extension, which introduces the concept of instructions that may be operations (MOPs). MOPs are initially defined to simply write zero to x[rd], but are designed to be redefined by later extensions to perform some other action. The Zimop extension defines an encoding space for 40 MOPs.

It is sometimes desirable to define instruction-set extensions whose instructions, rather than raising illegal-instruction exceptions when the extension is not implemented, take no useful action (beyond writing x[rd]). For example, programs with control-flow integrity checks can execute correctly on implementations without the corresponding extension, provided the checks are simply ignored. Implementing these checks as MOPs allows the same programs to run on implementations with or without the corresponding extension. Although similar in some respects to HINTs, MOPs cannot be encoded as HINTs, because unlike HINTs, MOPs are allowed to alter architectural state.

The Zimop extension defines 32 MOP instructions named mop.r.n, where n is an integer between 0 and 31, inclusive. Unless redefined by another extension, these instructions simply write 0 to x[rd]. Their encoding allows future extensions to define them to read x[rs1], as well as write x[rd].

The Zimop extension additionally defines 8 MOP instructions named mop.rr.n, where n is an integer between 0 and 7, inclusive. Unless redefined by another extension, these instructions simply write 0 to x[rd]. Their encoding allows future extensions to define them to read x[rs1] and x[rs2], as well as write x[rd].

The recommended assembly syntax for mop.r.n is mop.r.n rd, rs1, with any x-register specifier being valid for either argument. Similarly for mop.rr.n, the recommended syntax is mop.rr.n rd, rs1, rs2. The extension that redefines a MOP may define an alternate assembly mnemonic.

These MOPs are encoded in the SYSTEM major opcode in part because it is expected their behavior will be modulated by privileged CSR state.

These MOPs are defined to write zero to x[rd], rather than performing no operation, to simplify instruction decoding and to allow testing the presence of features by branching on the zeroness of the result.

The MOPs defined in the Zimop extension do not carry a syntactic dependency from x[rs1] or x[rs2] to x[rd], though an extension that redefines the MOP may impose such a requirement.

Not carrying a syntactic dependence relieves straightforward implementations of reading x[rs1] and x[rs2].

1.1. "Zcmop" Compressed May-Be-Operations Extension, Version 0.1

This section defines the "Zcmop" extension, which defines eight 16-bit MOP instructions named c.mop.n, where n is an integer between 0 and 7, inclusive. c.mop.n is encoded in the reserved encoding space corresponding to c.lui xm, 0, where m=2n+1, as shown in Table Table 1. Unlike the MOPs defined in the Zimop extension, the c.mop.n instructions are defined to not write any register. Their encoding allows future extensions to define them to read register x[m].

Very few suitable 16-bit encoding spaces exist. This space was chosen because it already has unusual behavior with respect to the rd/rs1 field—​it encodes c.addi16sp when the field contains x2--and is therefore of lower value for most purposes.

Table 1. c.mop.n instruction encoding.

Mnemonic	Encoding	Redefinable to read register
c.mop.0	0110000010000001	x1
c.mop.1	0110000110000001	x3
c.mop.2	0110001010000001	x5
c.mop.3	0110001110000001	x7
c.mop.4	0110010010000001	x9
c.mop.5	0110010110000001	x11
c.mop.6	0110011010000001	x13
c.mop.7	0110011110000001	x15

The recommended assembly syntax for c.mop.n is simply the nullary c.mop.n. The possibly accessed register is implicitly xm.

The expectation is that each Zcmop instruction is equivalent to some Zimop instruction, but the choice of expansion (if any) is left to the extension that redefines the MOP. Note, a Zcmop instruction that does not write a value can expand into a write to x0.