clarify

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 68d38ca5e3fe293c40c94eb4e24ab5b8080f4eb4..75dfc06557215cd8d3020f7fa75e79dfb456e5f8 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -122,8 +122,8 @@ such large numbers of registers, even for Multi-Issue microarchitectures.
 
 * No new Interrupt types are required.
   (**No modifications to existing Power ISA are required either**).
-* GPR FPR and CR Field Register numbers are extended to 128.
-  A future version may extend to 256 or beyond [^extend][^futurevsx]
+* GPR FPR and CR Field Register numbers are extended to 128.  A future
+  version may extend to 256 or beyond or also extend VSX[^extend][^futurevsx]
 * 24-bits are needed within the main SVP64 Prefix (equivalent to a 2-bit XO)
 * Another 24-bit (a second 2-bit XO) is needed for a planned future encoding,
   currently named "SVP64-Single" [^likeext001]
@@ -539,7 +539,7 @@ operations.
 
 [[!tag opf_rfc]]
 
-[^msr]: an MSR bit, conceptually equivalent to `MSR.SF` and added for the same reasons, would suffice perfectly.
+[^msr]: an MSR bit or bits, conceptually equivalent to `MSR.SF` and added for the same reasons, would suffice perfectly.
 [^extend]: Prefix opcode space (or MSR bits) **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