From: lkcl Date: Mon, 30 Nov 2020 16:30:13 +0000 (+0000) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~1600 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=ebc3594892a97bed44c8ed8d053282e6f0de621f;p=libreriscv.git --- diff --git a/openpower/sv/16_bit_compressed.mdwn b/openpower/sv/16_bit_compressed.mdwn index b5526beb5..ffee17c93 100644 --- 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.