(no commit message)

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 67c87bd4a4b3ebb2d9fad5429382296007dbbce1..8bc64c28f5efe7c58ab04f41bf477d0578bf426c 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -279,6 +279,10 @@ These options provide the ability to cover the majority of Parallel
 3D GPU Conditions, saving a not inconsiderable number of instructions
 especially given the close interaction with CTR in hot-loops. 
 
+Also `SVLR` is introduced, which is a parallel twin of `LR`, and saving
+and restoring of LR and SVLR may be deferred until the final decision
+as to whether to branch.  In this way `sv.bclrl` does not corrupt `LR`.
+
 **SVP64Single**
 
 The `SVP64-Single` 24-bit encoding focusses primarily on ensuring that
@@ -294,11 +298,14 @@ all 64-bit encodings.
 
 This is a Computer Science term that needed first to be invented.
 There exists only one other Vertical-First Vector ISA in the world:
-Mitch Alsup's VVM Extension for the 66000.
+Mitch Alsup's VVM Extension for the 66000. Several people have
+independently derived Vertical-First: it simply did not have a
+Computer Science term associated with it.
 
 If we envisage register and Memory layout to be Horizontal and
-instructions to be vertical, and to then have some form of Loop
-System it is easier to conceptualise VF vs HF Mode:
+instructions to be Vertical, and to then have some form of Loop
+System (wherther Zero-Overhead or just branch-conditional based)
+it is easier to then conceptualise VF vs HF Mode:
 
 * Vertical-First progresses through *instructions* first before
   moving on to the next *register* (or Memory-address in the case
@@ -307,7 +314,27 @@ System it is easier to conceptualise VF vs HF Mode:
   through **registers** (or, register *elements* in traditional
   Cray-Vector ISAs) in full before moving on to the next instruction.
 
-
+Mitch Alsup's VVM Extension is a form of hardware-level auto-vectorisation
+based around Zero-Overhead Loops. Using a Variable-Length Encoding all
+loop-invariant registers are "tagged" such that the Hazard Management
+Engine may perform optimally and do less work in automatically identifying
+parallelism opportunities.
+With it not being appropriate to use Variable-Length Encoding in the Power
+ISA a different much more explicit strategy was taken in Simple-V.
+
+The biggest advantage inherent in Vertical-First is that it is very easy
+to introduce into compilers, because all looping, as far as the architecture
+is concerned, remains expressed as *Scalar assembler*. Whilst Mitch Alsup's
+VVM advocates auto-vectorisation and is limited in its ability to call
+functions, Simple-V's Vertical-First provides explicit control over the
+parallelism ("hphint") and also allows for full state to be stored/restored
+(SVLR combined with LR), permitting full function calls to be made.
+
+Simple-V Vertical-First Looping requires an explicit instruction to
+move `SVSTATE` regfile offsets forward: `svstep`. An early version of 
+Vectorised
+Branch-Conditional attempted to merge the functionality of `svstep`
+into `sv.bc`: it became CISC-like and was reverted.
 
 \newpage{}
 # Simple-V REMAP subsystem