From: lkcl Date: Sun, 3 Jul 2022 11:50:17 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~1391 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=e68fe8085160b506d9809bda2e2dd4d160450f03;p=libreriscv.git --- diff --git a/openpower/sv.mdwn b/openpower/sv.mdwn index b596be280..a7f5f2dd9 100644 --- a/openpower/sv.mdwn +++ b/openpower/sv.mdwn @@ -126,7 +126,7 @@ Core SVP64 instructions: Beyond this point are additional **Scalar** instructions related to specific workloads that have nothing to do with the SV Specification* -# Non-Simple-V Scalar instructions +# Optional Scalar instructions **Additional Instructions for specific purposes (not SVP64)** @@ -198,7 +198,7 @@ opcode space is required**. Even though they are currently placed in the EXT022 Sandbox, the "Management" instructions (setvl, svstep, svremap, svshape, svindex) are designed to fit cleanly into EXT019 (like `addpcis`) or other 5/6-bit Minor -XO area. +XO area that has space for Rc=1. That said: for the target workloads for which Scalable Vectors are typically used, the Scalar ISA on which those workloads critically rely @@ -223,7 +223,7 @@ 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 +As in 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. @@ -242,11 +242,12 @@ same level as add, popcnt and fld** * 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 +* even if ratified and even if the majority (mostly 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 + it would be highly likely these remaining instructions would need two + major opcodes. Fortuitously the v3.1 Spec states that + both EXT005 and EXT009 are available. **Additional observations** @@ -261,22 +262,27 @@ 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 +for SVP64 due to the availability of 2 extra bits. +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 +available for "Custom non-approved purposes" according to the Power +ISA Spec, is under severe design pressure as it is insufficient to hold the full extent of the instruction additions required to create a Hybrid 3D CPU-VPU-GPU. **Whilst SVP64 is only 5 instructions the heavy focus on VSX for the past 12 years has left the SFFS Level -anaemic and out-of-date compared to ARM and x86. This is partially -a blessing as the Scalar ISA has remained clean. Approximately +anaemic and out-of-date compared to ARM and x86.** +This is very much +a blessing, as the Scalar ISA has remained clean, making it +highly suited to RISC-paradigm Scalable Vector Prefixing. Approximately 100 additional (optional) Scalar Instructions are up for proposal to bring SFFS -up-to-date** +up-to-date # Other