From f98344f3e7db9e340c466b4b93972b43f08c3ca1 Mon Sep 17 00:00:00 2001 From: Andrew Waterman Date: Fri, 6 Oct 2023 16:31:54 -0700 Subject: Number c.mop instructions more intuitively h/t @jhauser-us --- src/images/wavedrom/c-mop.adoc | 2 +- src/zimop.adoc | 26 +++++++++++++------------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/src/images/wavedrom/c-mop.adoc b/src/images/wavedrom/c-mop.adoc index c66e80c..0aee8e4 100644 --- a/src/images/wavedrom/c-mop.adoc +++ b/src/images/wavedrom/c-mop.adoc @@ -4,7 +4,7 @@ { bits: 2, name: 0x1, type: 8 }, { bits: 5, name: 0x0 }, { bits: 1, name: 0x1, type: 4 }, - { bits: 3, name: 'n[2:0]', type: 4 }, + { bits: 3, name: 'n[3:1]', type: 4 }, { bits: 1, name: 0x0, type: 4 }, { bits: 1, name: 0x0 }, { bits: 3, name: 0x3 }, diff --git a/src/zimop.adoc b/src/zimop.adoc index 0b4db59..32f0841 100644 --- a/src/zimop.adoc +++ b/src/zimop.adoc @@ -63,14 +63,14 @@ 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, as shown in Table +instructions named `c.mop.__n__`, where __n__ is an odd integer between 1 and +15, inclusive. `c.mop.__n__` is encoded in the reserved encoding space +corresponding to `c.lui x__n__, 0`, 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__]`. +`x[__n__]`. include::images/wavedrom/c-mop.adoc[] [[c-mop]] @@ -86,18 +86,18 @@ therefore of lower value for most purposes. |=== |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` +|c.mop.1 | `0110000010000001` | `x1` +|c.mop.3 | `0110000110000001` | `x3` +|c.mop.5 | `0110001010000001` | `x5` +|c.mop.7 | `0110001110000001` | `x7` +|c.mop.9 | `0110010010000001` | `x9` +|c.mop.11 | `0110010110000001` | `x11` +|c.mop.13 | `0110011010000001` | `x13` +|c.mop.15 | `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__`. +`c.mop.__n__`. The possibly accessed register is implicitly `x__n__`. 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 -- cgit v1.1