From cd13dfa40fa1413b8355b306afb20bb1ae6cb49f Mon Sep 17 00:00:00 2001 From: lkcl Date: Mon, 30 Nov 2020 16:36:40 +0000 Subject: [PATCH] --- openpower/sv/16_bit_compressed.mdwn | 55 +++++++++++++++-------------- 1 file changed, 28 insertions(+), 27 deletions(-) diff --git a/openpower/sv/16_bit_compressed.mdwn b/openpower/sv/16_bit_compressed.mdwn index 4e9dd55de..3cd5482c4 100644 --- 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]] -- 2.30.2