ls001 update to 56-bit RESERVED from 55-bit area EXT200-231

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index c83abff52781d8e88eba542b053046e47468fed2..fd2c133ce247669828f1791fccbe51a5afd97cba 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -858,11 +858,11 @@ Shift-Immediate operations that require large quantity of Primary Opcodes.
 To ensure that there is room in future,
 it may be better to allocate 25% to `RESERVED`:
 
-| 0-5 | 6 | 7 | 8-31  | 32  | Description               |
-|-----|---|---|-------|-----|---------------------------|
-| PO9?| 1 | 0 | 0000  | x   | EXT300-363 or `RESERVED1` (32-bit) |
-| PO9?| 0 | x | xxxx  | 0b0 | EXT200-231 or `RESERVED2` (56-bit) |
-| PO9?| 0 | x | xxxx  | 0b1 | EXT232-263 and SVP64(/V/S) |
+| 0-5 | 6 | 7 | 8-31  | 32| Description                        |
+|-----|---|---|-------|---|------------------------------------|
+| PO9?| 1 | 0 | 0000  | x | EXT300-363 or `RESERVED1` (32-bit) |
+| PO9?| 0 | x | xxxx  | 0 | EXT200-232 or `RESERVED2` (56-bit) |
+| PO9?| 0 | x | xxxx  | 1 | EXT232-263 and SVP64(/V/S)         |
 
 The clear separation between Simple-V and non-Simple-V stops
 conflict in future RFCs, both of which get plenty of space.
@@ -908,28 +908,28 @@ Vectorisation of EXT001 or EXT009 is prohibited.
 |--------|---|---|-------|---------|
 | PO (9)?| 1 | 1 | nnnn  | SVP64:{EXT000-063} |
 
-**{EXT248-263}** bit6=new bit7=scalar
+**{EXT232-263}** bit6=new bit7=scalar
 
 This encoding represents the opportunity to introduce EXT248-263.
 It is a Scalar-word encoding, and does not require implementing
 SVP64 or SVP64-Single, but does require the Vector-space to be allocated.
-PO2 is in the range 0b11000 to 0b111111 to represent EXT248-263 respectively.
+PO2 is in the range 0b100000 to 0b1111111 to represent EXT232-263 respectively.
 
-| 0-5    | 6 | 7 | 8-31  | 32-3 | 34-37   | 38-63   |
-|--------|---|---|-------|------|---------|---------|
-| PO (9)?| 0 | 0 | 0000  | 0b11 |PO2[2:5] | {EXT248-263} |
+| 0-5    | 6 | 7 | 8-31  | 32 | 33-37   | 38-63   |
+|--------|---|---|-------|----|---------|---------|
+| PO (9)?| 0 | 0 | 0000  | 1  |PO2[1:5] | {EXT232-263} |
 
-**SVP64Single:{EXT248-263}** bit6=new bit7=scalar
+**SVP64Single:{EXT232-263}** bit6=new bit7=scalar
 
 This encoding, which is effectively "implicit VL=1"
 and comprising (from bits 8-31 being non-zero)
 *at least some* form of Augmentation, it represents the opportunity
-to Augment EXT248-263 with the SVP64Single capabilities.
+to Augment EXT232-263 with the SVP64Single capabilities.
 Must be allocated under Scalar *and* SVP64 simultaneously.
 
-| 0-5    | 6 | 7 | 8-31  | 32-3 | 34-37   | 38-63   |
-|--------|---|---|-------|------|---------|---------|
-| PO (9)?| 0 | 0 | !zero | 0b11 |PO2[2:5] | SVP64Single:{EXT248-263} |
+| 0-5    | 6 | 7 | 8-31  | 32 | 33-37   | 38-63   |
+|--------|---|---|-------|----|---------|---------|
+| PO (9)?| 0 | 0 | !zero | 1  |PO2[1:5] | SVP64Single:{EXT232-263} |
 
 **SVP64:{EXT248-263}** bit6=new bit7=vector
 
@@ -941,25 +941,28 @@ 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-3 | 34-37   | 38-63   |
-|--------|---|---|-------|------|---------|---------|
-| PO (9)?| 0 | 1 | nnnn  | 0b11 |PO2[2:5] | SVP64:{EXT248-263} |
+| 0-5    | 6 | 7 | 8-31  | 32 | 33-37   | 38-63   |
+|--------|---|---|-------|----|---------|---------|
+| PO (9)?| 0 | 1 | nnnn  | 1  |PO2[1:5] | SVP64:{EXT232-263} |
 
-**RESERVED2 / EXT300-363** bit6=old bit7=scalar
+**RESERVED1 / EXT300-363** bit6=old bit7=scalar
 
-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 a *degenerate duplicate* so may be allocated
-for other purposes.
+This is at the discretion of the ISA WG. Libre-SOC is *not*
+proposing the addition of EXT300-363: it is merely a possibility
 
 | 0-5    | 6 | 7 | 8-31  | 32-63   |
 |--------|---|---|-------|---------|
 | PO (9)?| 1 | 0 | 0000  | EXT300-363 or `RESERVED1` |
 
+**RESERVED2 / EXT200-231** bit6=new bit32=1
+
+This is at the discretion of the ISA WG. Libre-SOC is *not*
+proposing the addition of EXT200-231: it is merely a possibility
+
+| 0-5    | 6 | 7 | 8-31  | 32 | 33-37   | 38-63   |
+|--------|---|---|-------|----|---------|---------|
+| PO (9)?| 0 | x | nnnn  | 1  |PO2[1:5] | {EXT200-231} |
+
 \newpage{}
 # Example Legal Encodings and RESERVED spaces
 
@@ -1083,7 +1086,7 @@ This is an illegal attempt to place an EXT004 "Defined Word"
 This is not just illegal it is not even possible to achieve.
 If attempted, by dropping EXT004 into bits 32-37, the top two
 MSBs are actually *zero*, and the Vector EXT2nn space is only
-legal for Primary Opcodes in the range 248-263, where the top
+legal for Primary Opcodes in the range 232-263, where the top
 two MSBs are 0b11.  Thus this faulty attempt actually falls
 unintentionally
 into `RESERVED` "Non-Vectoriseable" Encoding space.