(no commit message)

diff --git a/openpower/sv.mdwn b/openpower/sv.mdwn
index 680760a45710eafc8350c3e12fd320a9cae299b7..3babea8c5a70a8203d2e3909811eafd2c27f022a 100644 (file)
--- a/openpower/sv.mdwn
+++ b/openpower/sv.mdwn
@@ -199,12 +199,14 @@ different results on different hardware depending on a
 "Silicon Partner" hardware choice. This choice catastrophically
 and irrevocably causes binary non-interoperability *despite being
 a "feature"*.  Explained in <https://m.youtube.com/watch?v=HNEm8zmkjBU>
+it is the exact same binary-incompatibility issue faced by Power ISA
+on its 32- to 64-bit transition: 32-bit hardware was **unable** to
+trap-and-emulate 64-bit binarues because the opcodes were (are) the same.
 
 It is therefore *guaranteed* that extensions to the register file
 width and quantity in Simple-V shall only be made in future by
 explicit means, ensuring binary compatibility.
 
-
 # Optional Scalar instructions
 
 **Additional Instructions for specific purposes (not SVP64)**
@@ -275,7 +277,35 @@ To protect SVP64 from damage, a "Hard Rule" has to be set:
      must correspondingly be added in the Scalar space with the exact same
      32-bit "Defined Word" or not at all.
 
-
+Some explanation of the above is needed.  Firstly, "Defined Word" is a term
+used in Section 1.6.3 of the Power ISA v3 1 Book I: it means, in short,
+"a 32 bit instruction", which can then be Prefixed by EXT001 to extend it
+to 64-bit. Prefixed-Prefixed (96-bit Variable-Length) encodings are
+prohibited in v3.1 and they are just as prohibited in Simple-V: it's too
+complex in hardware.
+
+Secondly, the term "Vectoriseable" was used.  This refers to "instructions
+which if SVP64-Prefixed are actually meaningful". `sc` is meaningless
+to Vectorise, for example, as is `sync` and `mtmsr` (there is only ever
+going to be one MSR).
+
+The problem comes if the rationale is applied, "Unvectoriseable opcodes
+can be allocated to alternative instructions within the SVP64 Opcode space",
+which unfortunately results in huge inadviseable complexity in HDL at the
+Decode Phase, attempting to discern between the two.  Worse than that,
+if the alternate 64-bit instruction is Vectoriseable but the 32-bit Scalar
+"Defined Word" is already allocated, how can there ever be a Scalar version
+of the alternate instruction? It would have to be added as a **completely
+different** 32-bit "Defined Word" and things go rapidly downhill in the
+Decoder from there.
+
+Therefore to avoid risk:
+
+* *even Unvectoriseable* "Defined Words" (`mtmsr`) must have the
+  corresponding SVP64 Prefixed Space `RESERVED`, permanently requiring
+  Illegal Instruction to be raised.
+* *Even instructions that may not be Scalar* ( although for various
+  practical reasons this is extremely rare if not impossible)
 
 # Other Scalable Vector ISAs