(no commit message)

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index c2397d8991d1c64dbf024ae5068a00400c02c3cc..7c3ea253f97222e0a81208da229a5135fc14a33b 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -710,34 +710,59 @@ that is as follows:
 
 * EXT009, like EXT001 of Public v3.1, is **defined** as a 64-bit
   encoding
-* bits 32-33 if 0b11 are indefinitely allocated to SVP64 Format
+* bits 32-33 if 0b11 are **defined** as allocated to SVP64 Format
   *regardless of what that is*
 * other combinations of bits 32-33 are `RESERVED` for other purposes
-
-
-There are unfortunately some inviolate requirements that directly place
-pressure on the EXT000-EXT063 (32-bit) opcode space to such a degree that
-it risks jeapordising the Power ISA. These requirements are:
-
-* all of the scalar operations must be Vectoriseable
-* all of the scalar operations intended for Vectorisation
-  must be in a 32-bit encoding (not prefixed-prefixed to 96-bit)
-* bringing Scalar Power ISA up-to-date from the past 12 years
-  needs 75% of two Major opcodes all on its own
-
-There exists a potential scheme which meets (exceeds) the above criteria,
-providing plenty of room for both Scalar (and Vectorised) operations,
-*and* provides SVP64-Single with room to grow.  It
-is based loosely around Public v3.1 EXT001 Encoding.[^ext001]
-
-| 0-5 | 6 | 7 | 8-31  | Description               |
-|-----|---|---|-------|---------------------------|
-| PO  | 0 | 0 | 0000  | new-suffix `RESERVED1`               |
-| PO  | 0 | 0 | !zero | new-suffix, scalar (SVP64Single), or `RESERVED3` |
-| PO  | 1 | 0 | 0000  | new scalar-only word, or `RESERVED2`               |
-| PO  | 1 | 0 | !zero | old-suffix, scalar (SVP64Single), or `RESERVED4` |
-| PO  | 0 | 1 | nnnn  | new-suffix, vector (SVP64)       |
-| PO  | 1 | 1 | nnnn  | old-suffix, vector (SVP64)       |
+  
+| 0-5 | 6 | 7 | 8-31  | 32:33 |  Description               |
+|-----|---|---|-------|-------|---------------------------|
+| PO9?| / | / | ////  | 11    | SVP64 (current and future) |
+| PO9?| / | / | ////  | 01    | RESERVED (other)          |
+| PO9?| / | / | ////  | 10    | RESERVED (other)          |
+| PO9?| / | / | ////  | 00    | RESERVED (other)          |
+
+This ensures that any potential for future conflict over uses of the
+EXT009 space, jeapordising Simple-V in the process, are avoided.
+
+SVP64 then becomes:
+
+| 0-5 | 6 | 7 | 8-31  | 32-3 | Description               |
+|-----|---|---|-------|------|---------------------------|
+| PO  | 0 | 0 | 0000  | 0b11 | `RESERVED1` or EXT300-363              |
+| PO  | 0 | 0 | !zero | 0b11 | SVP64Single:EXT200-263, or `RESERVED3` |
+| PO  | 1 | 0 | 0000  | 0b11 | EXT200-264 or `RESERVED2`               |
+| PO  | 1 | 0 | !zero | 0b11 | SVP64Single:EXT000-063 or `RESERVED4` |
+| PO  | 0 | 1 | nnnn  | 0b11 | SVP64:EXT200-263     |
+| PO  | 1 | 1 | nnnn  | 0b11 | SVP64:EXT000-063       |
+
+Where:
+
+* SVP64Single (`RESERVED3/4`) is *planned* for a future RFC
+* `RESERVED1` is available for general-purpose **never**-Simple-V
+  32-bit encodings
+
+The only potential difficulty (solvable with a mapping table)
+is in fulfilling the "uniform suffix" requirement for `SVP64:EXT000-063`
+(and SVP64Single in future). Example:
+
+| width | assembler | prefix?      | 32-3 | 34-63    | description   |
+|-------|-----------|--------------|------|-----------|---------------|
+| 32bit | fishmv    | none         | n/a  | 345678| scalar EXT0nn |
+| 64bit | ss.fishmv | 0x26!zero    | 0b11 | 345678| scalar SVP64Single:EXT0nn |
+| 64bit | sv.fishmv | 0x27nnnnnn   | 0b11 | 345678| vector SVP64:EXT0nn |
+
+In a 32-bit-only Encoding, EXT000-063 the requirement of the top two bits
+being 0b11 effectively **requires** 32-bit-only instructions to be in the
+numbering range 48-63. For `EXT248-263` this is clearly not a problem
+but to restrict Vectorisation to only `EXT048-063` just as clearly is.
+
+A solution therefore is to maintain a "mapping table" between PO in
+the range `EXT000-EXT047` to fit into the remaining 4 bits of PO2, where
+the pattern chosen should minimise the number of gates to the bare
+minimum.
+
+Note that this has no effect on or relation to other uses of bits 32-3
+(0b00/0b01/0b10)
 
 # Example Legal Encodings and RESERVED spaces
 
@@ -766,12 +791,13 @@ all cases. Anything other than this risks either damage (truncation
 of capabilities of Simple-V) or far greater complexity in the
 Decode Phase.
 
-A *potential* compromise is to reserve certain EXT2nn POs right
+This drives the compromise proposal (above) to reserve certain
+EXT2nn POs right
 across the board
 (in the Scalar Suffix side, irrespective of Prefix), some allocated
 to Simple-V, some not.  
 
-example, legal (sort-of) (edit, typo corrected)
+**example, legal (sort-of)*
 
 * 32bit fishmv EXT0nn 0x12345678 or
   64bit scalar EXT2nn 0x240000000 0x12345678
@@ -779,7 +805,7 @@ example, legal (sort-of) (edit, typo corrected)
 
 this is sort-of-not-illegal because the space is automatically reserved for trap-and-emulate of Vector fishmv by Lower SV Compliancy Levels.
 
-example ILLEGAL: (typo corrected)
+**example ILLEGAL:**
 
 * 32bit fredmv EXT0nn 0x12345678 or
   64bit scalar EXT2nn 0x240000000 0x12345678
@@ -787,7 +813,7 @@ example ILLEGAL: (typo corrected)
 
 the use of 0x12345678 for fredmv in scalar but fishmv in Vector is **not** okay.
 
-another illegal example: (typo corrected)
+**another illegal example:**
 
 * 32bit RESERVEDunallocated EXT0nn 0x12345678 or
   64bit scalar EXT2nn 0x240000000 0x12345678