(no commit message)

diff --git a/openpower/sv/16_bit_compressed.mdwn b/openpower/sv/16_bit_compressed.mdwn
index 4e9dd55dedce231c566d2ffc79b3d9b4d6d2e4db..3cd5482c43ae40492d27640f7d10c557089d1585 100644 (file)
--- a/openpower/sv/16_bit_compressed.mdwn
+++ b/openpower/sv/16_bit_compressed.mdwn
@@ -96,31 +96,6 @@ The reason for picking 2 contiguous Major v3.0B opcodes is illustrated below:
 If NNNNN is the same value (two contiguous Major v3.0B Opcodes) this
 saves gates at a critical part of the decode phase.
 
-## Comparison to VLE
-
-VLE was a means to reduce executable size through three interleaved methods:
-
-* (1) invention of 16 bit encodings (of exactly 16 bit in length)
-* (2) invention of 16+16 bit encodings (a 16 bit instruction format but with
-  an *additional* 16 bit immediate "tacked on" to the end, actually
-  making a 32-bit instruction format)
-* (3) seamless and transparent embedding and intermingling of the
-  above in amongst arbitrary v2.06/7 BE 32 bit instruction sequences,
-  with no additional state,
-  including when the PC was not aligned on a 4-byte boundary.
-
-Whilst (1) and (3) make perfect sense, (2) makes no sense at all given that, as inspection of "ori" and others show, I-Form 16 bit immediates is the "norm" for v2.06/7 and v3.0B standard instructions.  (2) in effect **is** a 32 bit instruction.  (2) **is not** a 16 bit instruction.
-
-*Why "reinvent" an encoding that is 32 bit, when there already exists a 32 bit encoding that does the exact same job?*
-
-Consequently, we do **not** envisage a scenario where (2) would ever be implemented, nor in the future would this Compressed Encoding be extended beyond 16 bit.  Compressed is Compressed and is **by definition** limited to precisely  - and only - 16 bit.
-
-The additional reason why that is the case is because VLE is exceptionally complex to implement.  In a single-issue, low clock rate "Embedded" environment for which VLE was originally designed, VLE was perfectly well matched.
-
-However this Compressed Encoding is designed for High performance multi-issue systems *as well* as Embedded scenarios, and consequently, the complexity of "deep packet inspection" down into the depths of a 16 bit sequence in order to ascertain if it might not be 16 bit after all, is wholly unacceptable.
-
-By eliminating such 16+16 (actually, 32bit conflation) tricks outlined in (2), Compressed is *specifically* designed to fit into a very small FSM, suitable for multi-issue, that in no way requires "deep-dive" analysis. Yet, despite it never being designed with 16 bit encodings in mind, is still suitable for retro-fitting onto OpenPOWER.
-
 ## ABI considerations
 
 Unlike RISC-V RVC, the above "context" encodings require state, to be stored
@@ -719,10 +694,36 @@ available register that fits the constraints) is:
        vrsave, vscr    (fixed)
        sfp             (fixed)
 
-# Demo of encoding that's backward-compatible with PowerISA v3.1 in both LE and BE mode
+# Appendix
+## Comparison to VLE
+
+VLE was a means to reduce executable size through three interleaved methods:
+
+* (1) invention of 16 bit encodings (of exactly 16 bit in length)
+* (2) invention of 16+16 bit encodings (a 16 bit instruction format but with
+  an *additional* 16 bit immediate "tacked on" to the end, actually
+  making a 32-bit instruction format)
+* (3) seamless and transparent embedding and intermingling of the
+  above in amongst arbitrary v2.06/7 BE 32 bit instruction sequences,
+  with no additional state,
+  including when the PC was not aligned on a 4-byte boundary.
+
+Whilst (1) and (3) make perfect sense, (2) makes no sense at all given that, as inspection of "ori" and others show, I-Form 16 bit immediates is the "norm" for v2.06/7 and v3.0B standard instructions.  (2) in effect **is** a 32 bit instruction.  (2) **is not** a 16 bit instruction.
+
+*Why "reinvent" an encoding that is 32 bit, when there already exists a 32 bit encoding that does the exact same job?*
+
+Consequently, we do **not** envisage a scenario where (2) would ever be implemented, nor in the future would this Compressed Encoding be extended beyond 16 bit.  Compressed is Compressed and is **by definition** limited to precisely  - and only - 16 bit.
+
+The additional reason why that is the case is because VLE is exceptionally complex to implement.  In a single-issue, low clock rate "Embedded" environment for which VLE was originally designed, VLE was perfectly well matched.
+
+However this Compressed Encoding is designed for High performance multi-issue systems *as well* as Embedded scenarios, and consequently, the complexity of "deep packet inspection" down into the depths of a 16 bit sequence in order to ascertain if it might not be 16 bit after all, is wholly unacceptable.
+
+By eliminating such 16+16 (actually, 32bit conflation) tricks outlined in (2), Compressed is *specifically* designed to fit into a very small FSM, suitable for multi-issue, that in no way requires "deep-dive" analysis. Yet, despite it never being designed with 16 bit encodings in mind, is still suitable for retro-fitting onto OpenPOWER.
+
+## Demo of encoding that's backward-compatible with PowerISA v3.1 in both LE and BE mode
 
 [[demo]]
 
-# Efficient Decoding Algorithm
+### Efficient Decoding Algorithm
 
 [[decoding]]