(no commit message)

diff --git a/openpower/sv/16_bit_compressed.mdwn b/openpower/sv/16_bit_compressed.mdwn
index b5526beb53a6ebfe73e794723546dc1fb886aef0..ffee17c93bf6b5c295c2cce788ae5a6beb9214a8 100644 (file)
--- a/openpower/sv/16_bit_compressed.mdwn
+++ b/openpower/sv/16_bit_compressed.mdwn
@@ -96,9 +96,31 @@ 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)
+* (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 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 instuction.  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 RVC, the above "context" encodings require state, to be stored
+Unlike RISC-V RVC, the above "context" encodings require state, to be stored
 in the PCR, MSR, or a dedicated SPR.  These bits (just like LE/BE 32bit
 mode and the IEEE754 FPCSR mode) all require taking that context into
 consideration.