From bfd306c981ede9e72384878bccd7f8c895fd2628 Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 18 Nov 2020 17:47:31 +0000 Subject: [PATCH] --- openpower/sv/16_bit_compressed.mdwn | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/openpower/sv/16_bit_compressed.mdwn b/openpower/sv/16_bit_compressed.mdwn index 295968e0f..45e3e9e4f 100644 --- a/openpower/sv/16_bit_compressed.mdwn +++ b/openpower/sv/16_bit_compressed.mdwn @@ -66,12 +66,16 @@ something to use them for: One possibility is that the 11 bits are used for bank selection, with some room for additional context such as altering the registers used -for the 16 bit operations (bank selection of which scalar regs) - -Another is to use the 11 bits for only the utmost commonly used -instructions. That being the case then even one of those 11 bits would -also need to be dedicated to saying if 16 bit mode is to be continued. -10 bits remain for actual opcodes, which is ridiculously tight. +for the 16 bit operations (bank selection of which scalar regs). +However the downside is that short sequences of Compressed instructions +become penalised by the fixed overhead. Even a single 16 bit instruction requires a 16 bit overhead to "gain access" to 16 bit "mode", making the exercise pointless. + +An alternative is to use the first 11 bits for only the utmost commonly used +instructions. That being the case then one of those 11 bits could +be dedicated to saying if 16 bit mode is to be continued, at which +point *all* 16 bits can be used for Compressed. +10 bits remain for actual opcodes, which is ridiculously tight, +however the opportunity to subsequently use all 16 bits is worth it. The reason for picking 2 contiguous Major v3.0B opcodes is illustrated below: -- 2.30.2