From 146cf4e17ce5acc6bb6ac9c8a0ed66883a317ab6 Mon Sep 17 00:00:00 2001 From: lkcl Date: Sun, 3 Jul 2022 11:43:20 +0100 Subject: [PATCH] --- openpower/sv.mdwn | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/openpower/sv.mdwn b/openpower/sv.mdwn index a669890a3..b596be280 100644 --- a/openpower/sv.mdwn +++ b/openpower/sv.mdwn @@ -221,10 +221,11 @@ submit RFCs once the External ISA WG RFC Process is in place and, in a wholly unsatisfactory manner have to *hope and trust* that OPF ISA WG Members are reading this and take it into consideration. +**Scalar Summary** + As above sections, it is emphasised strongly that Simple-V in no way critically depends on the 100 or so *Scalar* instructions also -being developed by Libre-SOC. Therefore the Opcode summary below is -again divided into two: SVP64, then Scalar instructions. +being developed by Libre-SOC. **None of these Draft opcodes are intended for private custom secret proprietary usage. They are all intended for entirely @@ -237,10 +238,18 @@ same level as add, popcnt and fld** requires multiple VA-Form operations (in greater numbers than EXT04 has spare) * space in EXT019 next to addpcis and crops is recommended - (or any 5-6 bit Minor XO areas) + (or any other 5-6 bit Minor XO areas) * many X-Form opcodes currently in EXT022 have no preference for a location at all, and may be moved to EXT059, EXT019, EXT031 or other much more suitable location. +* even if ratified and even if the majority (X-Form) + is moved to other locations the large immediate sizes of + the remaining bitmanip instructions means + it would be highly likely they would need two + major opcodes. Fortunately EXT005 and EXT009 are + available. + +**Additional observations** Note that there is no Sandbox allocation in the published ISA Spec for v3.1 EXT01 usage, and because SVP64 is already 64-bit Prefixed, @@ -249,6 +258,14 @@ would become a whopping 96-bit long instruction. Avoiding this situation is a high priority which in turn by necessity puts pressure on the 32-bit Major Opcode space. +SVP64 itself is already under pressure, being only 24 bits. If it is +not permitted to take up 25% of EXT001 then it would have to be proposed +in its own Major Opcode, which on first consideration would be beneficial +for SVP64. However when combined with the bitmanip scalar instructions +requiring two Major opcodes this would come to a grand total of 3 precious +Major opcodes. On balance, then, sacrificing 25% of EXT001 is the "least +difficult" choice. + Note also that EXT022, the Official Architectural Sandbox area is under severe design pressure as it is insufficient to hold the full extent of the instruction additions required to create -- 2.30.2