From: Luke Kenneth Casson Leighton Date: Sat, 10 Sep 2022 13:46:30 +0000 (+0100) Subject: footnotes X-Git-Tag: opf_rfc_ls005_v1~517 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=08a5077de2cdc2ee56cd1ac89cff97f66ec66526;p=libreriscv.git footnotes --- diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn index 35dbe1de3..7f16d17f0 100644 --- a/openpower/sv/rfc/ls001.mdwn +++ b/openpower/sv/rfc/ls001.mdwn @@ -296,9 +296,8 @@ it risks jeapordising the Power ISA. These requirements are: There exists a potential scheme which meets (exceeds) the above criteria, providing plenty of room for both Scalar (and Vectorised) operations, -*and* provides SVP64-Single with the same amount of room to grow. It -is based loosely around the existing Public v3.1 EXT001 Encoding -Scheme. +*and* provides SVP64-Single with room to grow. It +is based loosely around Public v3.1 EXT001 Encoding. [^ext001] | 0-5 | 6 | 7 | 8-31 | Description | |-----|---|---|-------|---------------------------| @@ -330,14 +329,7 @@ Scheme. * **SVP64** - a (well-defined, 2 years) DRAFT Proposal for a Vectorisation Augmentation of suffixes. -(*Recall that EXT100 to EXT163 is for -Public v3.1 64-bit-augmented Operations prefixed by EXT001, for which, -from Section 1.6.3, bit 6 is set to 1. This concept is where -the above scheme originated. Section 1.6.3 uses the term "defined word" -to refer to pre-existing EXT000-EXT063 32-bit instructions so prefixed -to create the new numbering EXT100-EXT163, respectively*) - -For the needs identified by Libre-SOC's team, one of the `RESERVED` spaces *needs* allocation to new POs, the other does not: +For the needs identified by Libre-SOC's team, one of the `RESERVED` spaces *needs* allocation to new POs, the other does not. [^only2] | | Scalar (bit7=0,8-31=0000) | Scalar (bit7=0,8-31=!zero)| Vector (bit7=1) | |----------|---------------------------|---------------------------|------------------| @@ -535,4 +527,7 @@ operations. [^msr]: an MSR bit, conceptually equivalent to `MSR.SF` and added for the same reasons, would suffice perfectly. [^extend]: Prefix opcode space **must** be reserved in advance to do so, in order to avoid the catastrophic binary-incompatibility mistake made by RISC-V RVV and ARM SVE/2 [^likeext001]: SVP64-Single is remarkably similar to the "bit 1" of EXT001 being set to indicate that the 64-bits is to be allocated in full to a new encoding, but in fact SVP64-single still embeds v3.0 Scalar operations. -[^pseudorewrite]: elwidth overrides does however mean that all SFS / SFFS pseudocode will need rewriting to be in terms of XLEN. This has the indirect side-effect of automatically making a 32-bit Scalar Power ISA Specification possible, as well as a future 128-bit one (Cross-reference: RISC-V RV32 and RV128) +[^pseudorewrite]: elwidth overrides does however mean that all SFS / SFFS pseudocode will need rewriting to be in terms of XLEN. This has the indirect side-effect of automatically making a 32-bit Scalar Power ISA Specification possible, as well as a future 128-bit one (Cross-reference: RISC-V RV32 and RV128 +[^only2]: reminder that this proposal only needs 75% of two POs for Scalar instructions. The rest of EXT200-263 is for general use. +[^ext001]: Recall that EXT100 to EXT163 is for Public v3.1 64-bit-augmented Operations prefixed by EXT001, for which, from Section 1.6.3, bit 6 is set to 1. This concept is where the above scheme originated. Section 1.6.3 uses the term "defined word" to refer to pre-existing EXT000-EXT063 32-bit instructions so prefixed to create the new numbering EXT100-EXT163, respectively +