(no commit message)

diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn
index 3cf0c50133fd549cd92194b97b0c42b375a6a297..71ffd21ac45b2a8da796d189fad9964112e57dde 100644 (file)
--- a/openpower/sv/rfc/ls010.mdwn
+++ b/openpower/sv/rfc/ls010.mdwn
@@ -34,15 +34,22 @@ and counting up as you move rightwards to the LSB end). All bit ranges are inclu
 element numbering however is LSB0 ordering** which is a different convention from that used
 elsewhere in the Power ISA.
 
-64-bit instructions are split into two 32-bit words, the prefix and the
-suffix. The prefix always comes before the suffix in PC order.
+The SVP64 prefix always comes before the suffix in PC order and must be considered
+an independent "Defined word" that augments the behaviour of the following instruction,
+but does **not** change the actual Decoding of that following instruction.
+**All prefixed instructions retain their non-prefixed encoding and definition**.
+
+*Architectural Resource Allocation note: it is **prohibited** to accept RFCs which
+fundamentally violate this hard requirement.  Under no circumstances must the
+Suffix space have an alternate instruction encoding allocated within SVP64 that is
+entirely different from the non-prefixed Defined Word. Hardware Implementors
+critically rely on this inviolate guarantee to implement High-Performance Multi-Issue
+micro-architectures that can sustain 100% throughput*
 
 | 0:5    | 6:31         | 32:63        |
 |--------|--------------|--------------|
 | EXT09  | v3.1  Prefix | v3.0/1  Suffix |
 
-svp64 fits into the "reserved" portions of the v3.1 prefix, making it possible for svp64, v3.0B (or v3.1 including 64 bit prefixed) instructions  to co-exist in the same binary without conflict.
-
 Subset implementations in hardware are permitted, as long as certain
 rules are followed, allowing for full soft-emulation including future
 revisions.  Compliancy Subsets exist to ensure minimum levels of binary