From 1e88a87af45c8bfcfce8a3856888ab90090b3fb1 Mon Sep 17 00:00:00 2001 From: Andrew Waterman Date: Mon, 18 Sep 2023 15:19:34 -0700 Subject: Incorporate Krste's feedback on Zimop chapter --- src/zimop.adoc | 45 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 35 insertions(+), 10 deletions(-) (limited to 'src/zimop.adoc') diff --git a/src/zimop.adoc b/src/zimop.adoc index 1d17686..79035e6 100644 --- a/src/zimop.adoc +++ b/src/zimop.adoc @@ -2,15 +2,15 @@ == "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. +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. [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. +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 @@ -51,8 +51,9 @@ 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]`. +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. NOTE: Not carrying a syntactic dependence relieves straightforward implementations of reading `x[rs1]` and `x[rs2]`. @@ -64,16 +65,40 @@ implementations of reading `x[rs1]` and `x[rs2]`. 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__]`. +corresponding to `c.lui x__m__, 0`, where __m__=2__n__+1, as shown in Table +<>. +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__]`. include::images/wavedrom/c-mop.adoc[] [[c-mop]] +NOTE: 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. + +[[tab:c-mop]] +.`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` +|=== + 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 +Zimop instruction with `rd`=`x0`, but the choice of expansion (if any) is left to the extension that redefines the MOP. -- cgit v1.1