(no commit message)

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index b7067bbf8b519eb52c5994671d701b234db28bea..e3def5e060bf966fdb20be0967ead4893f235c5b 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -550,7 +550,9 @@ Setting a simple inviolate rule helps avoid this scenario but does
 need to be borne in mind when discussing potential allocation
 schemes, as well as when new Vectoriseable Opcodes are proposed
 for addition by future RFCs: the opcodes **must** be uniformly
-added to Scalar **and** Vector spaces.
+added to Scalar **and** Vector spaces, or added in one and reserved
+in the other, or
+not added at all in either.[^whoops]
 
 \newpage{}
 # Potential Opcode allocation solution
@@ -1129,3 +1131,4 @@ operations.
 [^autovec]: Compiler auto-vectorisation for best exploitation of SIMD and Vector ISAs on Scalar programming languages (c, c++) is an Indusstry-wide known-hard decades-long problem. Cross-reference the number of hand-optimised assembler algorithms.
 [^hphint]: intended for use when the compiler has determined the extent of Memory or register aliases in loops: `a[i] += a[i+4]` would necessitate a Vertical-First hphint of 4
 [^svshape]: although SVSHAPE0-3 should, realistically, be regarded as high a priority as SVSTATE, and given corresponding SVSRR and SVLR equivalents, it was felt that having to context-switch **five** SPRs on Interrupts and function calls was too much.
+[^whoops]: two efforts were made to mix non-uniform encodings into Simple-V space: one deliberate to see how it would go, and one accidental. They both went extremely badly, the deliberate one costing two months to add then remove.