(no commit message)

diff --git a/openpower/sv.mdwn b/openpower/sv.mdwn
index 3babea8c5a70a8203d2e3909811eafd2c27f022a..bd013acda12c5518cf80c8201d65ac745495a649 100644 (file)
--- a/openpower/sv.mdwn
+++ b/openpower/sv.mdwn
@@ -299,13 +299,31 @@ 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:
+Therefore to avoid risk and long-term damage to the Power ISA:
 
 * *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
+  Illegal Instruction to be raised (the 64-bit encoding allocated
+  to `sv.mtmsr` if illegally attempted must be **defined** to
+  raise an Exception)
+* *Even instructions that may not be Scalar* (although for various
   practical reasons this is extremely rare if not impossible)
+  which have no meaning or use as a 32-bit Scalar "Defined Word", **must**
+  still have the Scalar "Defined Word" `RESERVED` in the scalar
+  opcode space, as an Illegal Instruction.
+
+A good example of the former is `mtmsr` because there is only one
+MSR register, and a good example of the latter is [[sv/mv.x]]
+which is so deeply problematic to add to any Scalar ISA that it was
+rejected outright and an alternative route taken (Indexed REMAP).
+
+Another good example would be Cross Product which has no meaning
+at all in a Scalar ISA. If any such Vector operation were ever added,
+it would be **critically** important to reserve the exact same *Scalar*
+opcode in the *Scalar* Power ISA opcode space.  There are
+good reasons why Cross Product has not been proposed, but it serves
+to illustrate the point as far as Architectural Resource Allocation is
+concerned.
 
 # Other Scalable Vector ISAs