update

diff --git a/simple_v_extension.mdwn b/simple_v_extension.mdwn
index e05f44de6f4369967a72e8b7fd8dd3d27be5523b..cb2ba08fe3152665cdb7a0e419fd4f656f3a1e63 100644 (file)
--- a/simple_v_extension.mdwn
+++ b/simple_v_extension.mdwn
@@ -693,45 +693,6 @@ hardware-parallelism in the ALUs is not deployed.  A hybrid is also
 permitted (as used in Broadcom's VideoCore-IV) however this must be
 *entirely* transparent to the ISA.
 
-### Under review / discussion: remove CSR vector length, use VSETVL <a name="vsetvl"></a>
-
-**DECISION: 11jun2018 - CSR vector length removed, VSETVL determines
-length on all regs**
-
-So the issue is as follows:
-
-* CSRs are used to set the "span" of a vector (how many of the standard
-  register file to contiguously use)
-* VSETVL in RVV works as follows: it sets the vector length (copy of which
-  is placed in a dest register), and if the "required" length is longer
-  than the *available* length, the dest reg is set to the MIN of those
-  two.
-* **HOWEVER**... in SV, *EVERY* vector register has its own separate
-  length and thus there is no way (at the time that VSETVL is called) to
-  know what to set the vector length *to*.
-* At first glance it seems that it would be perfectly fine to just limit
-  the vector operation to the length specified in the destination
-  register's CSR, at the time that each instruction is issued...
-  except that that cannot possibly be guaranteed to match
-  with the value *already loaded into the target register from VSETVL*.
-
-Therefore a different approach is needed.
-
-Possible options include:
-
-* Removing the CSR "Vector Length" and always using the value from
-  VSETVL.  "VSETVL destreg, counterreg, #lenimmed" will set VL *and*
-  destreg equal to MIN(counterreg, lenimmed), with register-based
-  variant "VSETVL destreg, counterreg, lenreg" doing the same.
-* Keeping the CSR "Vector Length" and having the lenreg version have
-  a "twist": "if lengreg is vectorised, read the length from the CSR"
-* Other (TBD)
-
-The first option (of the ones brainstormed so far) is a lot simpler.
-It does however mean that the length set in VSETVL will apply across-the-board
-to all src1, src2 and dest vectorised registers until it is otherwise changed
-(by another VSETVL call).  This is probably desirable behaviour.
-
 ## Branch Instruction:
 
 Branch operations use standard RV opcodes that are reinterpreted to be
@@ -1988,6 +1949,45 @@ summary: don't restrict / remove.  it's fine.
 
 <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/g3feFnAoKIM>
 
+## Under review / discussion: remove CSR vector length, use VSETVL <a name="vsetvl"></a>
+
+**DECISION: 11jun2018 - CSR vector length removed, VSETVL determines
+length on all regs**.  This section kept for historical reasons.
+
+So the issue is as follows:
+
+* CSRs are used to set the "span" of a vector (how many of the standard
+  register file to contiguously use)
+* VSETVL in RVV works as follows: it sets the vector length (copy of which
+  is placed in a dest register), and if the "required" length is longer
+  than the *available* length, the dest reg is set to the MIN of those
+  two.
+* **HOWEVER**... in SV, *EVERY* vector register has its own separate
+  length and thus there is no way (at the time that VSETVL is called) to
+  know what to set the vector length *to*.
+* At first glance it seems that it would be perfectly fine to just limit
+  the vector operation to the length specified in the destination
+  register's CSR, at the time that each instruction is issued...
+  except that that cannot possibly be guaranteed to match
+  with the value *already loaded into the target register from VSETVL*.
+
+Therefore a different approach is needed.
+
+Possible options include:
+
+* Removing the CSR "Vector Length" and always using the value from
+  VSETVL.  "VSETVL destreg, counterreg, #lenimmed" will set VL *and*
+  destreg equal to MIN(counterreg, lenimmed), with register-based
+  variant "VSETVL destreg, counterreg, lenreg" doing the same.
+* Keeping the CSR "Vector Length" and having the lenreg version have
+  a "twist": "if lengreg is vectorised, read the length from the CSR"
+* Other (TBD)
+
+The first option (of the ones brainstormed so far) is a lot simpler.
+It does however mean that the length set in VSETVL will apply across-the-board
+to all src1, src2 and dest vectorised registers until it is otherwise changed
+(by another VSETVL call).  This is probably desirable behaviour.
+
 ## Implementation Paradigms <a name="implementation_paradigms"></a>
 
 TODO: assess various implementation paradigms.  These are listed roughly