stronger words on PO9 encoding

diff --git a/openpower/sv/po9_encoding.mdwn b/openpower/sv/po9_encoding.mdwn
index a330f70afac3b4659483f10fe85b6027e80712d4..f4cf7a02ac2c0ff424e8f932b50a99f1ba0216eb 100644 (file)
--- a/openpower/sv/po9_encoding.mdwn
+++ b/openpower/sv/po9_encoding.mdwn
@@ -100,28 +100,33 @@ Also that RESERVED1 and 2 are candidates for future Major opcode
 areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
 they may equally be allocated entirely differently.
 
-*Architectural Resource Allocation Note: **under no circumstances** must
-different Defined Words be allocated within any `EXT{z}` prefixed or
-unprefixed space for a given value of `z` of 0, 2 or 3. Even if UnVectoriseable
-an instruction Defined Word space must have the exact same Instruction
-and exact same Instruction Encoding in all spaces being RESERVED (Illegal
-Instruction Trap if UnVectoriseable) or not be allocated at all.
-This is required as an inviolate hard rule governing Primary Opcode 9
-that may not be revoked under any circumstances. A useful way to think
-of this is that the Prefix Encoding is, like the 8086 REP instruction,
-an independent 32-bit Defined Word. The only semi-exceptions are
-the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.*
-
-Note a special application of the above paragraph: due to the fact that
-the Prefix Encodings are independent, **by definition** two new Sandbox
-areas "come into being" in an **inviolate** manner (i.e.  they may not
-be called anything else, nor may they be revoked rescinded removed or
-recalled), named `SVP64:EXT022` and `SVP64Single:EXT022`.  The **only
-way** that these two new areas may be revoked is if EXT022 itself
-is revoked.  **All and any** re-definitions modifications enhancements
-clarifications that apply to EXT022 **also apply to these two new areas**
-because due to the Prefixes being independent Defined Words the three
-areas are actually one and the same area.
+*Architectural Resource Allocation Note: Similar to ARM's `MOVPRFX`
+instruction and the original x86 REP instruction, despite "influence" over
+the Suffix, the Suffix is entirely independent of the Prefix.  Therefore
+**under no circumstances** must different Defined Words (different from
+the same **Un-Prefixed** Defined Word) be allocated within any `EXT{z}`
+prefixed or unprefixed space for a given value of `z` of 0, 2 or 3: the
+results would be catastrophic.  Even if UnVectoriseable an instruction
+Defined Word space **must** have the exact same Instruction and exact same
+Instruction Encoding in all spaces being RESERVED (Illegal Instruction
+Trap if UnVectoriseable) or not be allocated at all.  This is required
+as an inviolate hard rule governing Primary Opcode 9 that may not be
+revoked under any circumstances. A useful way to think of this is that
+the Prefix Encoding is, like the 8086 REP instruction, an independent
+32-bit Defined Word. The only semi-exceptions are the Post-Increment
+Mode of LD/ST-Update and Vectorised Branch-Conditional.*
+
+Note a particular consequence of the application of the above paragraph:
+due to the fact that the Prefix Encodings are independent, **by
+definition** two new Sandbox areas "come into being" in an **inviolate**
+manner (i.e.  they may not be called anything else, nor may they
+be revoked rescinded removed or recalled), named `SVP64:EXT022` and
+`SVP64Single:EXT022`.  The **only way** that these two new areas may be
+revoked is if EXT022 itself is revoked.  **All and any** re-definitions
+modifications enhancements clarifications that apply to EXT022 **also
+apply to these two new areas** because due to the Prefixes being
+independent Defined Words the three areas are actually one and the same
+area, just as *all* Scalar Defined Words are.
 
 Encoding spaces and their potential are illustrated: