1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
[[zimop]]
== "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
perform no useful operation and raise no exceptions, but might be redefined by
later extensions to perform some other action. The Zimop extension defines an
encoding space for 40 MOPs.
[NOTE]
====
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.
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]`.
include::images/wavedrom/mop-r.adoc[]
[[mop-r]]
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]`.
include::images/wavedrom/mop-rr.adoc[]
[[mop-rr]]
NOTE: 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.
NOTE: These MOPs are encoded in the SYSTEM major opcode in part because it is
expected their behavior will be modulated by privileged CSR state.
NOTE: 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 are not guaranteed to carry
a syntactic dependency from `x[rs1]` or `x[rs2]` to `x[rd]`.
NOTE: Not carrying a syntactic dependence relieves straightforward
implementations of reading `x[rs1]` and `x[rs2]`.
<<<
=== "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 x__m__, 0`, where __m__=2__n__+1. These instructions
are defined to not write any register. Their encoding allows future extensions
to define them to read register `x[__m__]`.
include::images/wavedrom/c-mop.adoc[]
[[c-mop]]
NOTE: The recommended assembly syntax for `c.mop.__n__` is simply the nullary
`c.mop.__n__`. The possibly accessed register is implicitly `x__m__`.
NOTE: 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.
|
