From 9ca2e1eda94a775d7562067b5f5dc643f76270c5 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Sun, 30 Apr 2023 12:52:30 +0100 Subject: [PATCH] stronger words on PO9 encoding --- openpower/sv/po9_encoding.mdwn | 49 +++++++++++++++++++--------------- 1 file changed, 27 insertions(+), 22 deletions(-) diff --git a/openpower/sv/po9_encoding.mdwn b/openpower/sv/po9_encoding.mdwn index a330f70af..f4cf7a02a 100644 --- 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: -- 2.30.2