(no commit message)

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 809b4d324790c68f0ec6deed5259e94e24228f1c..40f1fb974c6c71ec68520d61910c8d1400ce9273 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -76,8 +76,7 @@ Illegal Instruction trap-and-emulate is also out of the question.
 **Simple-V guarantees binary interoperability** by defining fixed
 register file bitwidths and size for all instructions.  This does
 mean that `RESERVED` space is important to have in SVP64, in order
-to provide future expanded register file bitwidths and sizes.
-
+to provide future expanded register file bitwidths and sizes. [^msr]
 # Hardware Implementations
 
 The fundamental principle of Simple-V is that it sits between Issue and
@@ -526,6 +525,7 @@ operations.
 
 [[!tag opf_rfc]]
 
+[^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)