add new encoding table section

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 4495d068d8c25dc9d968a3439e5f9dfea422cfa6..d8adeb3a6f265cc3042c2a4eb17c0cafca87d697 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -393,6 +393,90 @@ The issues of allocation for bitmanip etc. from Libre-SOC is therefore
 overwhelmingly made moot. The only downside is that there is no
 `SVP64-Reserved` which will have to be achieved with SPRs (PCR or MSR).
 
+\newpage{}
+**EXT000-EXT031**
+
+These are Scalar word-encodings. Often termed "v3.0 Scalar" in this document
+Power ISA v3.1 Section 1.6.3 Book I calls it a "Scalar word".
+
+| 0-5    | 6-31   |
+|--------|--------|
+| PO     | EXT000-031 Scalar (v3.0 or v3.1) operation |
+
+**RESERVED2 / EXT300-363**
+
+This is entirely at the discretion of the ISA WG. Libre-SOC is *not*
+proposing the addition of EXT300-363: it is merely a possibility for
+future.  The reason the space is not needed is because this is within
+the realm of Scalar-extended (SVP64Single), and with the 24-bit prefix
+area being all-zero (bits 8-31) this is defined as "having no augmentation"
+(in the Simple-V Specification it is termed `Scalar Identity Behaviour`).
+This in turn makes this prefix *entirely redundant* so may be allocated
+for other purposes.
+
+| 0-5    | 6 | 7 | 8-31  | 32-63   |
+|--------|---|---|-------|---------|
+| PO (9)?| 1 | 0 | 0000  | EXT300-363 or `RESERVED1` |
+
+**{EXT200-263}**
+
+This encoding represents the opportunity to introduce EXT200-263. 
+It is a Scalar-word encoding, and does not require implementing
+SVP64 or SVP64-Single.
+PO2 is in the range 0b00000 to 0b11111 to represent EXT200-263 respectively.
+
+| 0-5    | 6 | 7 | 8-31  | 32-37  | 38-63   |
+|--------|---|---|-------|--------|---------|
+| PO (9)?| 0 | 0 | 0000  | PO2    | {EXT200-263} |
+
+**SVP64Single:{EXT200-263}**
+
+This encoding, which is effectively VL=1 and comprising (from bits 8-31)
+*at least some* form of Augmentation, it represents the opportunity
+to Augment EXT200-263 with the SVP64Single capabilities.
+Instructions may not be placed in this category without also being
+implemented as pure Scalar.
+
+| 0-5    | 6 | 7 | 8-31  | 32-37  | 38-63   |
+|--------|---|---|-------|--------|---------|
+| PO (9)?| 0 | 0 | !zero | PO2    | SVP64Single:{EXT200-263} |
+
+**SVP64Single:{EXT000-063}**
+
+This encoding, identical to SVP64Single:{EXT200-263},
+introduces SVP64Single Augmentation of v3.0 Scalar word instructions.
+All meanings must be identical to EXT000 to EXT063, and is is likewise
+prohibited to add an instruction in this area without also adding
+the exact same (non-Augmented) instruction in EXT000-063 with the
+exact same Scalar word.
+PO2 is in the range 0b00000 to 0b11111 to represent EXT000-063 respectively.
+Augmenting EXT001 is prohibited.
+
+**SVP64:{EXT200-263}** 
+
+This encoding, which permits VL to be dynamic (settable from GPR or CTR)
+is the Vectorisation of EXT200-263.
+Instructions may not be placed in this category without also being
+implemented as pure Scalar *and* SVP64Single. Unlike SVP64Single
+however, there is **no reserved encoding** (bits 8-24 zero).
+VL=1 may occur dynamically
+at runtime, even when bits 8-31 are zero.
+
+| 0-5    | 6 | 7 | 8-31  | 32-37  | 38-63   |
+|--------|---|---|-------|--------|---------|
+| PO (9)?| 0 | 1 | nnnn  | PO2    | SVP64:{EXT200-263} |
+
+**SVP64:{EXT000-063}**
+
+This encoding is identical to **SVP64:{EXT200-263}** except it
+is the Vectorisation of existing v3.0/3.1 Scalar-words, EXT000-063.
+All the same rules apply with the addition that
+Vectorisation of EXT001 is prohibited.
+
+| 0-5    | 6 | 7 | 8-31  | 32-37  | 38-63   |
+|--------|---|---|-------|--------|---------|
+| PO (9)?| 1 | 1 | nnnn  | PO2    | SVP64:{EXT000-063} |
+
 \newpage{}
 # Use cases