From 3d0650a791c817ab2481770b920c4f321737c8c6 Mon Sep 17 00:00:00 2001 From: lkcl Date: Sat, 1 Apr 2023 00:47:31 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls010.mdwn | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn index 32b5ad4eb..f2d47701c 100644 --- a/openpower/sv/rfc/ls010.mdwn +++ b/openpower/sv/rfc/ls010.mdwn @@ -25,7 +25,7 @@ Subsystem" similar to the 5 decades-old Zilog Z80 `LDIR` instruction and to the Prefix instruction. More advanced features are similar to the Z80 `CPIR` instruction. If viewed one-dimensionally as an actual Vector ISA it introduces over 1.5 million 64-bit Vector instructions. SVP64, the instruction -format, is therefore best viewed as an orthogonal RISC-paradigm "Prefixing" +format used by Simple-V, is therefore best viewed as an orthogonal RISC-paradigm "Prefixing" subsystem instead. Except where explicitly stated all bit numbers remain as in the rest of @@ -135,7 +135,8 @@ MSB0 ordering). When exclusively using MSB0-numbering, SVP64 becomes unnecessarily complex to both express and subsequently understand: the required conditional subtractions from 63, -31, 15 and 7 unfortunately become a hostile minefield, obscuring both +31, 15 and 7 needed to express the fact that elements are LSB0-sequential +unfortunately become a hostile minefield, obscuring both intent and meaning. Therefore for the purposes of this section the more natural **LSB0 numbering is assumed** and it is left to the reader to translate to MSB0 numbering. @@ -208,7 +209,7 @@ Performance designs. ## Scalar Identity Behaviour SVP64 is designed so that when the prefix is all zeros, and - VL=1, no effect or +VL=1, no effect or influence occurs (no augmentation) such that all standard Power ISA v3.0/v3 1 instructions covered by the prefix are "unaltered". This is termed `scalar identity behaviour` (based on the mathematical @@ -305,11 +306,11 @@ new 64-bit encoding space, alongside EXT1xx. | 0-5 | 6 | 7 | 8-31 | 32| Description | |-----|---|---|-------|---|------------------------------------| -| PO | 0 | x | xxxx | 0 | EXT200-231 or `RESERVED2` (56-bit) | +| PO | 0 | x | xxxx | 0 | `RESERVED2` (56-bit) | | PO | 0 | 0 | !zero | 1 | SVP64Single:EXT232-263, or `RESERVED3` | | PO | 0 | 0 | 0000 | 1 | Scalar EXT232-263 | | PO | 0 | 1 | nnnn | 1 | SVP64:EXT232-263 | -| PO | 1 | 0 | 0000 | x | EXT300-363 or `RESERVED1` (32-bit) | +| PO | 1 | 0 | 0000 | x | `RESERVED1` (32-bit) | | PO | 1 | 0 | !zero | n | SVP64Single:EXT000-063 or `RESERVED4` | | PO | 1 | 1 | nnnn | n | SVP64:EXT000-063 | @@ -320,9 +321,9 @@ can be zero (termed `scalar identity behaviour`). This prohibition allows SVP64Single to share its Encoding space with Scalar Ext232-263 and Scalar EXT300-363. -Also that RESERVED1 and 2 are given *tentative* naming EXT200-231 and -EXT300-363 respectively, in reality they are completely unused and -future use may allocate entirely different naming. +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 @@ -333,7 +334,8 @@ being RESERVED 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.* +an independent 32-bit Defined Word. The only semi-exceptions are +the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.* Ecoding spaces and their potential are illustrated: -- 2.30.2