(no commit message)

diff --git a/openpower/sv/16_bit_compressed.mdwn b/openpower/sv/16_bit_compressed.mdwn
index 0a4c4e368903f0844ad258943c485644d74cb15a..5f169c322429ae45b5ac6d21973da4f7a029a07b 100644 (file)
--- a/openpower/sv/16_bit_compressed.mdwn
+++ b/openpower/sv/16_bit_compressed.mdwn
@@ -37,6 +37,8 @@ prefix format from SV-P64, as well.
 
 Potential ways to reduce pressure on the 16 bit space are:
 
+* To use more than one v3.0B Major Opcode, preferably an odd-even
+  contiguous pair
 * To provide "paging".  This involves bank-switching to alternative optimised encodings for specific workloads
 * To enter "16 bit mode" for durations specified at the start
 * To reserve one bit of every 16 bit instruction to indicate that the 16 bit mode is to continue to be sustained
@@ -68,6 +70,15 @@ 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.
 
+The reason for picking 2 contiguous Major v3.0B opcodes is illustrated belo:
+
+     0 1 2 3 4 5 6 7 8 9 a b c d e f|
+    |major op..0| LO Half C space   |
+    |major op..1| HI Half C space   |
+    |N N N N N|<--11 bits C space-->|
+
+If NNNNN is the same value (two contiguous Major v3.0B Opcodes) this saves gates at a critical part of the decode phase.
+
 # Opcode Allocation Ideas
 
 * one bit from the 16-bit mode is used to indicate that 32-bit mode