footnotes

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 35dbe1de38734056b2cc2306a2b8d3ee58d0d7c3..7f16d17f02c2c9405bc0dce4276c6cae5900e8ef 100644 (file)
--- 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
+