move po9 encoding to its own separate page

diff --git a/openpower/sv/po9_encoding.mdwn b/openpower/sv/po9_encoding.mdwn
new file mode 100644 (file)
index 0000000..9714d69
--- /dev/null
+++ b/openpower/sv/po9_encoding.mdwn
@@ -0,0 +1,71 @@
+# New 64-bit Instruction Encoding spaces
+
+The following seven new areas are defined within Primary Opcode 9 (EXT009)
+as a new 64-bit encoding space, alongside Primary Opcode 1
+(EXT1xx).
+
+| 0-5 | 6 | 7 | 8-31  | 32| Description                        |
+|-----|---|---|-------|---|------------------------------------|
+| PO  | 0 | x | xxxx  | 0 | `RESERVED2` (57-bit) |
+| PO  | 0 | 0 | !zero | 1 | SVP64Single:EXT232-263, or `RESERVED3` |
+| PO  | 0 | 0 | 0000  | 1 | Scalar EXT232-263               |
+| PO  | 0 | 1 | nnnn  | 1 | SVP64:EXT232-263     |
+| PO  | 1 | 0 | 0000  | x | `RESERVED1` (32-bit) |
+| PO  | 1 | 0 | !zero | n | SVP64Single:EXT000-063 or `RESERVED4` |
+| PO  | 1 | 1 | nnnn  | n | SVP64:EXT000-063       |
+
+Note that for the future SVP64Single Encoding (currently RESERVED3 and 4)
+it is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,
+for which bits 8-31 can be zero (termed `scalar identity behaviour`). This
+prohibition allows SVP64Single to share its Encoding space with Scalar
+Ext232-263 and Scalar EXT300-363.
+
+Also that RESERVED1 and 2 are candidates for future Major opcode
+areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
+they may equally be allocated entirely differently.
+
+*Architectural Resource Allocation Note: **under no circumstances** must
+different Defined Words be allocated within any `EXT{z}` prefixed
+or unprefixed space for a given value of `z`. Even if UnVectoriseable
+an instruction Defined Word space must have the exact same Instruction
+and exact same Instruction Encoding in all spaces being RESERVED - Illegal
+Instruction Trap - if UnVectoriseable) or not be allocated at all.
+This is required as an inviolate hard rule governing Primary Opcode 9
+that may not be revoked under any circumstances. A useful way to think
+of this is that the Prefix Encoding is, like the 8086 REP instruction,
+an independent 32-bit Defined Word. The only semi-exceptions are
+the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.*
+
+Encoding spaces and their potential are illustrated:
+
+| Encoding | Available bits | Scalar | Vectoriseable | SVP64Single  |
+|----------|----------------|--------|---------------|--------------|
+|EXT000-063| 32             | yes    | yes           |yes           |
+|EXT100-163| 64             | yes    | no            |no            |
+|RESERVED2 | 57             | N/A    |not applicable |not applicable|
+|EXT232-263| 32             | yes    | yes           |yes           |
+|RESERVED1 | 32             | N/A    | no            |no            |
+
+Notes:
+
+* Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
+  thus inherently UnVectoriseable as the EXT1xx prefix is 32-bit
+  on top of an SVP64 prefix which is 32-bit on top of a Defined Word
+  and the complexity at the Decoder becomes too great for High
+  Performance Multi-Issue systems.
+* RESERVED2 presently remains unallocated as of yet and therefore its
+  potential is not yet defined (Not Applicable).
+* RESERVED1 is also unallocated at present, but it is known in advance
+  that the area is UnVectoriseable and also cannot be Prefixed with
+  SVP64Single.
+* Considerable care is needed both on Architectural Resource Allocation
+  as well as instruction design itself.  Once an instruction is allocated
+  in an UnVectoriseable area it can never be Vectorised without providing
+  an entirely new Encoding.
+
+[[!tag standards]]
+
+--------
+
+\newpage{}
+

diff --git a/openpower/sv/rfc/Makefile b/openpower/sv/rfc/Makefile
index c7254460710b8a126a41a2fd757cbdcb88850741..a06826d424601740d818d47d08ab391680518a38 100644 (file)
--- a/openpower/sv/rfc/Makefile
+++ b/openpower/sv/rfc/Makefile
@@ -4,6 +4,7 @@ LSO10_FILES = ls010.mdwn ../svp64.mdwn \
               ../normal.mdwn \
               ../ldst.mdwn \
               ../branches.mdwn \
+              ../po9_encoding.mdwn \
               ../cr_ops.mdwn
 
 ls010.pdf: $(LS010_FILES)
@@ -18,6 +19,7 @@ ls010.pdf: $(LS010_FILES)
                -V linkcolor=blue \
                -f markdown \
                     sv/rfc/ls010.mdwn \
+                    sv/po9_encoding.mdwn \
                     sv/svp64.mdwn \
                     sv/normal.mdwn \
                     sv/ldst.mdwn \

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index 3e7d948336c9fbb5a9147635b8f35600fbbf2d7f..6486b075d74c43ffe002a4d6c2e48f1fbc8b4488 100644 (file)
--- a/openpower/sv/svp64.mdwn
+++ b/openpower/sv/svp64.mdwn
@@ -1001,74 +1001,3 @@ Now at its own page: [[svp64/appendix]]
 [[!tag standards]]
 
 \newpage{}
-
-
-# New 64-bit Instruction Encoding spaces
-
-The following seven new areas are defined within Primary Opcode 9 (EXT009)
-as a new 64-bit encoding space, alongside Primary Opcode 1
-(EXT1xx).
-
-| 0-5 | 6 | 7 | 8-31  | 32| Description                        |
-|-----|---|---|-------|---|------------------------------------|
-| PO  | 0 | x | xxxx  | 0 | `RESERVED2` (57-bit) |
-| PO  | 0 | 0 | !zero | 1 | SVP64Single:EXT232-263, or `RESERVED3` |
-| PO  | 0 | 0 | 0000  | 1 | Scalar EXT232-263               |
-| PO  | 0 | 1 | nnnn  | 1 | SVP64:EXT232-263     |
-| PO  | 1 | 0 | 0000  | x | `RESERVED1` (32-bit) |
-| PO  | 1 | 0 | !zero | n | SVP64Single:EXT000-063 or `RESERVED4` |
-| PO  | 1 | 1 | nnnn  | n | SVP64:EXT000-063       |
-
-Note that for the future SVP64Single Encoding (currently RESERVED3 and 4)
-it is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,
-for which bits 8-31 can be zero (termed `scalar identity behaviour`). This
-prohibition allows SVP64Single to share its Encoding space with Scalar
-Ext232-263 and Scalar EXT300-363.
-
-Also that RESERVED1 and 2 are candidates for future Major opcode
-areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
-they may equally be allocated entirely differently.
-
-*Architectural Resource Allocation Note: **under no circumstances** must
-different Defined Words be allocated within any `EXT{z}` prefixed
-or unprefixed space for a given value of `z`. Even if UnVectoriseable
-an instruction Defined Word space must have the exact same Instruction
-and exact same Instruction Encoding in all spaces being RESERVED - Illegal
-Instruction Trap - if UnVectoriseable) or not be allocated at all.
-This is required as an inviolate hard rule governing Primary Opcode 9
-that may not be revoked under any circumstances. A useful way to think
-of this is that the Prefix Encoding is, like the 8086 REP instruction,
-an independent 32-bit Defined Word. The only semi-exceptions are
-the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.*
-
-Encoding spaces and their potential are illustrated:
-
-| Encoding | Available bits | Scalar | Vectoriseable | SVP64Single  |
-|----------|----------------|--------|---------------|--------------|
-|EXT000-063| 32             | yes    | yes           |yes           |
-|EXT100-163| 64             | yes    | no            |no            |
-|RESERVED2 | 57             | N/A    |not applicable |not applicable|
-|EXT232-263| 32             | yes    | yes           |yes           |
-|RESERVED1 | 32             | N/A    | no            |no            |
-
-Notes:
-
-* Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
-  thus inherently UnVectoriseable as the EXT1xx prefix is 32-bit
-  on top of an SVP64 prefix which is 32-bit on top of a Defined Word
-  and the complexity at the Decoder becomes too great for High
-  Performance Multi-Issue systems.
-* RESERVED2 presently remains unallocated as of yet and therefore its
-  potential is not yet defined (Not Applicable).
-* RESERVED1 is also unallocated at present, but it is known in advance
-  that the area is UnVectoriseable and also cannot be Prefixed with
-  SVP64Single.
-* Considerable care is needed both on Architectural Resource Allocation
-  as well as instruction design itself.  Once an instruction is allocated
-  in an UnVectoriseable area it can never be Vectorised without providing
-  an entirely new Encoding.
-
---------
-
-\newpage{}
-