https://bugs.libre-soc.org/show_bug.cgi?id=985
[libreriscv.git] / simple_v_extension / sv_prefix_proposal.rst
index 5ac706b68a1a891657681af4c433d9cb5cb9321a..9cfdd854164087ec888047631c6292d33320239c 100644 (file)
@@ -1,3 +1,5 @@
+[[!tag oldstandards]]
+
 SimpleV Prefix (SVprefix) Proposal v0.3
 =======================================
 
@@ -12,6 +14,7 @@ into 32, 48 and 64 bit RV formats, to provide Vectorisation context
 on a per-instruction basis.
 
 .. _Specification: http://libre-riscv.org/simple_v_extension/specification/
+.. _Appendix: http://libre-riscv.org/simple_v_extension/appendix/
 
 .. contents::
 
@@ -39,7 +42,7 @@ Options
 The following partial / full implementation options are possible:
 
 * SVPrefix augments the main Specification_
-* SVPregix operates independently, without the main spec VL (and MVL)
+* SVPrefix operates independently, without the main spec VL (and MVL)
   CSRs (in any priv level)
 * SVPrefix operates independently, without the main spec SUBVL CSRs
   (in any priv level)
@@ -88,7 +91,7 @@ instructions.
 ============================
 
 The 48 bit format is further extended with the full 128-bit range on all
-source and destination registers, and the option to set both VL and MVL
+source and destination registers, and the option to set both SVSTATE.VL and SVSTATE.MVL
 is provided.
 
 48-bit Instruction Encodings
@@ -130,9 +133,9 @@ Table showing correspondance between P48-*-type and RV32-*-type.
 These are bits 47:18 (RV32 shifted up by 16 bits):
 
 +---------------+---------------+
-| Encoding      | 47:18         |
+| Encoding      | RV32 Encoding |
 +---------------+---------------+
-| RV32 Encoding | 31:2          |
+| 47:32         | 31:2          |
 +---------------+---------------+
 | P48-LD-type   | RV32-I-type   |
 +---------------+---------------+
@@ -210,12 +213,15 @@ this is now set to "0b0111111".
 
 The extra bit for src and dest registers provides the full range of
 up to 128 registers, when combined with the extra bit from the 48 bit
-prefix as well.  VLtyp encodes how (whether) to set VL and MAXVL.
+prefix as well.  VLtyp encodes how (whether) to set SVPSTATE.VL and SVPSTATE.MAXVL.
 
 VLtyp field encoding
 ====================
 
-NOTE: VL and MVL below are local to SVPregix and, if non-default, are tracked through SVPSTATE, not the main Specification_ STATE. If default (all zeros) then STATE VL and MVL apply to this instruction.
+NOTE: VL and MVL below are local to SVPrefix and, if non-default,
+will update the src and dest element offsets in SVPSTATE, not the main
+Specification_ STATE. If default (all zeros) then STATE VL and MVL apply
+to this instruction, and STATE.srcoffs (etc) will be used.
 
 +-----------+-------------+--------------+----------+----------------------+
 | VLtyp[11] | VLtyp[10:6] | VLtyp[5:1]   | VLtyp[0] | comment              |
@@ -229,7 +235,9 @@ NOTE: VL and MVL below are local to SVPregix and, if non-default, are tracked th
 | 1         |  VLdest     |  MVL-immed   | 1        | MVL immed mode       |
 +-----------+-------------+--------------+----------+----------------------+
 
-Note: when VLtyp is all zeros, the main Specification_ VL and MVL apply to this instruction. If called outside of a VBLOCK or if sv.setvl has not set VL, the operation is "scalar".
+Note: when VLtyp is all zeros, the main Specification_ VL and MVL apply
+to this instruction. If called outside of a VBLOCK or if sv.setvl has
+not set VL, the operation is "scalar".
 
 Just as in the VBLOCK format, when bit 11 of VLtyp is zero:
 
@@ -255,10 +263,41 @@ operations such as LOAD-MULTI / STORE-MULTI, for saving and restoration
 of large batches of registers in context-switches or function calls.
 
 Note that VLtyp's VL and MVL are not the same as the main Specification_
-VL or MVL, and that loops will alter srcoffs and destoffs in SVPSTATE in VLtype nondefault mode, but in STATE if VLtype=0.
+VL or MVL, and that loops will alter srcoffs and destoffs in SVPSTATE in VLtype nondefault mode, but the srcoffs and destoffs in STATE, if VLtype=0.
 
 Furthermore, the execution order and exception handling must be exactly
-the same as in the main spec.
+the same as in the main spec (Program Order must be preserved)
+
+Pseudocode for SVPSTATE.VL:
+
+.. parsed-literal::
+
+    # pseudocode
+
+    regs = [0u64; 128];
+    vl = 0;
+
+    // instruction fields:
+    rd = get_rd_field();
+    vlmax = get_immed_field();
+
+    // handle illegal instruction decoding
+    if vlmax > XLEN {
+        trap()
+    }
+
+    // calculate VL
+    if rs1 == 0 { // rs1 is x0
+        vl = vlmax
+    } else {
+        vl = min(regs[rs1], vlmax)
+    }
+
+    // write rd
+    if rd != 0 {
+        // rd is not x0
+        regs[rd] = vl
+    }
 
 vs#/vd Fields' Encoding
 =======================
@@ -341,8 +380,7 @@ immediate. Should this be considered?
 Sub-Vector Length (svlen) Field Encoding
 ========================================
 
-NOTE: svlen is the same as the main spec SUBVL, and modifies the STATE
-CSR. The same caveats apply to svlen as do to SUBVL.
+NOTE: svlen is not the same as the main spec SUBVL.  When nondefault (not zero) SVPSTATE context is used for Sub vector loops. However is svlen is zero, STATE and SUBVL is used instead.
 
 Bitwidth, from VL's perspective, is a multiple of the elwidth times svlen.
 So within each loop of VL there are svlen sub-elements of elwidth in size,
@@ -399,6 +437,13 @@ Predication (pred) Field Encoding
 Twin-predication (tpred) Field Encoding
 =======================================
 
+Twin-predication (ability to associate two predicate registers with an
+instruction) applies to MV, FCLASS, LD and ST.  The same format also
+applies to integer-branch-compare operations although it is **not** to be
+considered "twin" predication.  In the case of integer-branch-compare
+operations, the second register (if enabled) stores the results of the
+element comparisons.  See Appendix_ for details.
+
 +-------+------------+--------------------+----------------------------------------------+
 | tpred | Mnemonic   | Predicate Register | Meaning                                      |
 +=======+============+====================+==============================================+
@@ -583,19 +628,28 @@ the main specification.
 
 * VL
 * MVL
-* STATE
+* SVPSTATE
 * SUBVL
 
 Associated SET and GET on the CSRs is exactly as in the main spec as well
 (including CSRRWI and CSRRW differences).
 
-Note that if all of VL/MVL, SUBVL, VLtyp and svlen are all chosen by an
-implementor not to be implemented, the STATE CSR is not required.
+Note that if both VLtyp and svlen are not implemented, SVPSTATE is not required. Also if VL and SUBVL are not implemented, STATE from the main Specification_ is not required either.
 
 However if partial functionality is implemented, the unimplemented bits
-in STATE must be zero, and, in the UNIX Platform, an illegal exception
+in STATE and SVPSTATE must be zero, and, in the UNIX Platform, an illegal exception
 **MUST** be raised if unsupported bits are written to.
 
+SVPSTATE fields are exactly the same layout as STATE:
+
++----------+----------+----------+----------+----------+---------+---------+
+| (31..28) | (27..26) | (25..24) | (23..18) | (17..12) | (11..6) | (5...0) |
++----------+----------+----------+----------+----------+---------+---------+
+| rsvd     | dsvoffs  | subvl    | destoffs | srcoffs  | vl      | maxvl   |
++----------+----------+----------+----------+----------+---------+---------+
+
+However note that where STATE stores the scalar register number to be used as VL, SVPSTATE.VL actually contains the actual VL value, in an identical fashion to RVV.
+
 Additional Instructions
 =======================