(no commit message)

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index fcb3830a9ce201cf4b8e10168640da0c69024c59..17618fef08682db4ea872613d8382339d824fdd4 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -535,6 +535,11 @@ is if a conflicting Scalar instruction is added by another Stakeholder,
 which then turns out to be Vectoriseable: it would then have to be
 added to the Vector Space with a *completely different Defined Word*
 and things go rapidly downhill in the Decode Phase from there.
+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.
 
 \newpage{}
 # Potential Opcode allocation solution