(no commit message)

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index 5c0b3d9ea0d51d559802501eeb2fb683799bff03..1942922f886c8babc1dba0a094fa93511adb6e4d 100644 (file)
--- a/openpower/sv/svp64.mdwn
+++ b/openpower/sv/svp64.mdwn
@@ -94,18 +94,18 @@ highly suited to High-Performance Computation (HPC), Supercomputing,
 and parallel GPU Workloads.
 
 *Architectural Resource Allocation note: at present it is possible to perform
-partial parallel decode of the SVP64 24-bit Encoding at the same time
+partial parallel decode of the SVP64 24-bit Encoding Area at the same time
 as decoding of the Suffix. Multi-Issue Implementations may even
 Decode multiple 32-bit words in parallel and follow up with a second
-cycle of joining Prefix and Suffix "after-the-fact".  
+cycle of joining Prefix and Suffix "after-the-fact". 
 Mixing and overlaying 64-bit Opcode Encodings into the
 {SVP64 24-bit Prefix}{Defined Word-instruction} space creates
-a hard dependency that catastrophically damages Multi-Issue Decoding.
+a hard dependency that catastrophically damages Multi-Issue Decoding by
+greatly complexifying Parallel Instruction-Length Detection.
 Therefore it has to be prohibited to accept RFCs
-which fundamentally violate this hard requirement.  Under no circumstances
-must the Suffix space have an alternate instruction encoding allocated
- that is entirely different from the non-prefixed Defined
-Word.*
+which fundamentally violate the following hard requirement: **under no circumstances**
+must the use of SVP64 24-bit Suffixes **also** imply a different Opcode space
+from **any** non-prefixed Word, even RESERVED or Illegal Words.*
 
 Subset implementations in hardware are permitted, as long as certain
 rules are followed, allowing for full soft-emulation including future