(no commit message)

diff --git a/simple_v_extension/specification.mdwn b/simple_v_extension/specification.mdwn
index 08e9c73e8bd7722782d0b5fe6eeb4910551c6c7d..47303ea937b5be187ac8f40c1a803525c298e3d5 100644 (file)
--- a/simple_v_extension/specification.mdwn
+++ b/simple_v_extension/specification.mdwn
@@ -130,7 +130,8 @@ The access pattern for these groups of CSRs in each mode follows the
 same pattern for other CSRs that have M-Mode and S-Mode "mirrors":
 
 * In M-Mode, the S-Mode and U-Mode CSRs are separate and distinct.
-* In S-Mode, accessing and changing of the M-Mode CSRs is identical
+* In S-Mode, accessing and changing of the M-Mode CSRs is transparently
+  identical
   to changing the S-Mode CSRs.  Accessing and changing the U-Mode
   CSRs is permitted.
 * In U-Mode, accessing and changing of the S-Mode and U-Mode CSRs
@@ -145,9 +146,11 @@ to be set up, for context-switching to take place, and, on return
 back to the higher privileged mode, the CSRs of that mode will be
 exactly as they were.  Thus, it becomes possible for example to
 set up CSRs suited best to aiding and assisting low-latency fast
-context-switching *once and only once*, without the need for
+context-switching *once and only once* (for example at boot time), without the need for
 re-initialising the CSRs needed to do so.
 
+Another interesting side effect of separate S Mode CSRs is that Vectorised saving of the entire register file to the stack is a single instruction (accidental provision of LOAD-MULTI semantics). It can even be predicated, which opens up some very interesting possibilities.
+
 The xEPCVLIW CSRs must be treated exactly like their corresponding xepc equivalents. See VLIW section for details.
 
 ## MAXVECTORLENGTH (MVL) <a name="mvl" />
@@ -2351,10 +2354,6 @@ answer: they're not vectorised, so not a problem
 
 ---
 
-TODO: update elwidth to be default / 8 / 16 / 32
-
----
-
 TODO: document different lengths for INT / FP regfiles, and provide
 as part of info register. 00=32, 01=64, 10=128, 11=reserved.