(no commit message)
[libreriscv.git] / simple_v_extension / sv_prefix_proposal.rst
index 1c6e0b8609920ba9bf99e5a384f4ef1524da6a23..bdfd571d21058b2e26385d5b974220b83024ec68 100644 (file)
@@ -1,8 +1,18 @@
 SimpleV Prefix (SVprefix) Proposal v0.3
 =======================================
 
-This proposal is designed to be able to operate without SVcsr, but not to
-require the absence of SVcsr.
+This proposal is designed to be able to operate without SVorig, but not to
+require the absence of SVorig See Specification_.
+
+If required, the STATE, VL, MVL and SUBVL CSRs all operate according to the main specification: hypothetically an implementor could choose not to support setting of VL, MVL or SUBVL (only allowing them to be set to a value of 1). STATE would then not be required either.
+
+If support for SUBVL is to be provided, storing of the sub-vector offsets and SUBVL itself (and context switching of the same) in the STATE CSRs are mandatory.
+
+If support for VL is to be provided, storing of VL, MVL and the dest and src offsets (and context switching of the same) in the STATE CSRs are mandatory.
+
+.. _Specification: http://libre-riscv.org/simple_v_extension/specification/
+
+.. contents::
 
 Conventions
 ===========
@@ -25,7 +35,7 @@ and using 001 (H) in the floating-point load/store *width* field.
 
 Compressed Instructions
 =======================
-This proposal doesn't include any prefixed RVC instructions, instead, it will
+This proposal does not include any prefixed RVC instructions, instead, it will
 include 32-bit instructions that are compressed forms of SVprefix 48-bit
 instructions, in the same manner that RVC instructions are compressed forms of
 RVI instructions. The compressed instructions will be defined later by
@@ -85,7 +95,7 @@ bits 47:18 (RV32 shifted up by 16 bits):
 +---------------+---------------+
 | RV32 Encoding | 31:2          |
 +---------------+---------------+
-| P48-LD-type   | RV32-I-type   | 
+| P48-LD-type   | RV32-I-type   |
 +---------------+---------------+
 | P48-ST-type   | RV32-S-Type   |
 +---------------+---------------+
@@ -120,7 +130,7 @@ Table showing Standard RV32 encodings:
 | RV32-FR-type  + funct5      + fmt   + rs2[4:0] + rs1[4:0] + rm     | rd[4:0]  + opcode + 1      + 1          |
 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+------------+
 
-64-bit Instruction Encodings <a name="64-bit-prefix"></a>
+64-bit Instruction Encodings
 ============================
 
 Where in the 48 bit format the prefix is "0b0011111" in bits 0 to 6, this is
@@ -142,49 +152,45 @@ now set to "0b0111111".
 +--------------+-------+--------+--------+--------+--------+
 | Encoding     | 63    | 62     | 61     | 60     | 59:48  |
 +--------------+-------+--------+--------+--------+--------+
-| P64-LD-type  | rd[6] | rs1[6] |        |        | SVtyp  |
+| P64-LD-type  | rd[6] | rs1[6] |        |        | VLtyp  |
 +--------------+-------+--------+--------+--------+--------+
-| P64-ST-type  |       | rs1[6] | rs2[6] |        | SVtyp  |
+| P64-ST-type  |       | rs1[6] | rs2[6] |        | VLtyp  |
 +--------------+-------+--------+--------+--------+--------+
-| P64-R-type   | rd[6] | rs1[6] | rs2[6] |        | SVtyp  |
+| P64-R-type   | rd[6] | rs1[6] | rs2[6] |        | VLtyp  |
 +--------------+-------+--------+--------+--------+--------+
-| P64-I-type   | rd[6] | rs1[6] |        |        | SVtyp  |
+| P64-I-type   | rd[6] | rs1[6] |        |        | VLtyp  |
 +--------------+-------+--------+--------+--------+--------+
-| P64-U-type   | rd[6] |        |        |        | SVtyp  |
+| P64-U-type   | rd[6] |        |        |        | VLtyp  |
 +--------------+-------+--------+--------+--------+--------+
-| P64-FR-type  |       | rs1[6] | rs2[6] |        | SVtyp  |
+| P64-FR-type  |       | rs1[6] | rs2[6] |        | VLtyp  |
 +--------------+-------+--------+--------+--------+--------+
-| P64-FI-type  | rd[6] | rs1[6] | rs2[6] |        | SVtyp  |
+| P64-FI-type  | rd[6] | rs1[6] | rs2[6] |        | VLtyp  |
 +--------------+-------+--------+--------+--------+--------+
-| P64-FR4-type | rd[6] | rs1[6] | rs2[6] | rs3[6] | SVtyp  |
+| P64-FR4-type | rd[6] | rs1[6] | rs2[6] | rs3[6] | VLtyp  |
 +--------------+-------+--------+--------+--------+--------+
 
 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.  SVtyp encodes how (whether) to set VL and MAXVL.
+prefix as well.  VLtyp encodes how (whether) to set VL and MAXVL.
 
-SVtyp field encoding
+VLtyp field encoding
 ====================
 
 +-----------+-------------+--------------+----------+----------------------+
-| SVtyp[11] | SVtyp[10:6] | SVtyp[5:1]   | SVtyp[0] | comment              |
+| VLtyp[11] | VLtyp[10:6] | VLtyp[5:1]   | VLtyp[0] | comment              |
 +-----------+-------------+--------------+----------+----------------------+
 | 0         |  000000     | 00000        |  0       | no change to VL/MVL  |
 +-----------+-------------+--------------+----------+----------------------+
-| 0         |  VLdest!=0  | 00000        |  0       | reserved             |
-+-----------+-------------+--------------+----------+----------------------+
 | 0         |  VLdest     | VLEN         |  vlt     | VL imm/reg mode (vlt)|
 +-----------+-------------+--------------+----------+----------------------+
-| 1         |  VLdest     |  MVL+VL-immed           | MVL/VL immed mode    |
+| 1         |  VLdest     | MVL+VL-immed | 0        | MVL+VL immed mode    |
++-----------+-------------+--------------+----------+----------------------+
+| 1         |  VLdest     |  MVL-immed   | 1        | MVL immed mode       |
 +-----------+-------------+--------------+----------+----------------------+
 
-Notes:
-
-* When SVtyp is all zeros, neither VL nor MVL are changed
-* SVtype[11]=0, SVtype[5:0]=0 and SVtype[10:6] non-zero is a reserved encoding.
-  Its uses raises an illegal instruction exception.
+Note: when VLtyp is all zeros, neither VL nor MVL are changed.
 
-Just as in the VLIW format, when bit 11 of SVtyp is zero:
+Just as in the VLIW format, when bit 11 of VLtyp is zero:
 
 * if vlt is zero, bits 1 to 5 specify the VLEN as a 5 bit immediate
   (offset by 1: 0b00000 represents VL=1, 0b00001 represents VL=2 etc.)
@@ -192,13 +198,17 @@ Just as in the VLIW format, when bit 11 of SVtyp is zero:
   from which VL is set.  x0 is not permitted
 * VL goes into the scalar register VLdest (if VLdest is not x0)
 
-When bit 11 of SVtype is 1:
+When bit 11 of VLtype is 1:
 
-* both MAXVL and VL are set to (VLenimmed+1)
-* the same value goes into the scalar register VLdest (if VLdest is not x0)
+* if VLtyp[0] is zero, both MAXVL and VL are set to (imm+1).  The same
+  value goes into the scalar register VLdest (if VLdest is not x0)
+* if VLtyp[0] is 1, MAXVL is set to (imm+1).
+  VL will be truncated to within the new range (if VL was greater
+  than the new MAXVL).  The new VL goes into the scalar register VLdest
+  (if VLdest is not x0).
 
-This gives the option to set up VL in a "loop mode" (SVtype[11]=0) or
-in a "one-off" mode (SVtype[11]=1) which sets both MVL and VL to the
+This gives the option to set up VL in a "loop mode" (VLtype[11]=0) or
+in a "one-off" mode (VLtype[11]=1) which sets both MVL and VL to the
 same immediate value.  This may be most useful for one-off Vectorised
 operations such as LOAD-MULTI / STORE-MULTI, for saving and restoration
 of large batches of registers in context-switches or function calls.
@@ -273,18 +283,24 @@ Open question: RVV overloads the width field of LOAD-FP/STORE-FP using the bit 2
 Sub-Vector Length (svlen) Field Encoding
 =======================================================
 
+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, just like in a SIMD architecture. When svlen is set to 0b00 (indicating svlen=1) no such SIMD-like behaviour exists and the subvectoring is disabled.
+
+Predicate bits do not apply to the individual sub-vector elements, they apply to the entire subvector group. This saves instructions on setup of the predicate.
+
 +----------------+-------+
 | svlen Encoding | Value |
 +================+=======+
-| 00             | 4     |
+| 00             | 1     |
 +----------------+-------+
-| 01             | 1     |
+| 01             | 2     |
 +----------------+-------+
-| 10             | 2     |
+| 10             | 3     |
 +----------------+-------+
-| 11             | 3     |
+| 11             | 4     |
 +----------------+-------+
 
+TODO : resolve interactions when SV VLIW Mode is active, as SVLEN is also a CSR.
+
 Predication (pred) Field Encoding
 =================================
 
@@ -370,6 +386,8 @@ separate 64-bit destination registers (rd+0, rd+1, rd+2, rd+3)
 that are sign-extended from the source width size out to 64-bit,
 because that is itype=0b00 (uXLEN).
 
+Note also: changing elwidth creates packed elements that, depending on VL, may create vectors that do not fit perfectly onto XLEM sized rehistry file boundaries. This does  NOT result in the destruction of the MSBs of the last register written to at the end of a VL loop. More details on how to handle this are described in the main Specification_.
+
 Signedness Decision Procedure
 =============================
 
@@ -483,39 +501,23 @@ defined 48-bit instruction encoding for the base instruction.
 CSR Registers
 =============
 
-+--------+-----------------+---------------------------------------------------+
-| Name   | Legal Values    | Meaning                                           |
-+========+=================+===================================================+
-| VL     | 0 <= VL <= XLEN | Vector Length. The number of sub-vectors operated |
-|        |                 | on by vector instructions.                        |
-+--------+-----------------+---------------------------------------------------+
-| Vstart | 0 <= VL < XLEN  | The sub-vector index to start execution at.       |
-|        |                 | Successful completion of all elements in a vector |
-|        |                 | instruction sets Vstart to 0. Set to the index of |
-|        |                 | the failing sub-vector when a vector instruction  |
-|        |                 | traps.  Used to resume execution of vector        |
-|        |                 | instructions after a trap. Is *NOT* "slow"        |
-+--------+-----------------+---------------------------------------------------+
+CSRs are the same as in the main Specification_, if associated functionality is implemented. They have the exact same meaning as in the main specification.
+
+* VL
+* MVL
+* STATE
+* SUBVL
+
 
 SetVL
 =====
 
 setvl rd, rs1, imm
+setvl rd, rs1
 
-imm is the amount of space allocated from the register file by the compiler.
+This is done the same as Standard SV.
+There is also a MVL CSR.  CSRRW and CSRRWI operate in the same way as in SV. See Specification_.
 
-Pseudocode:
-
-1. Trap if imm > XLEN.
-2. If rs1 is x0, then
-    1. Set VL to imm.
-3. Else If regs[rs1] > 2 * imm, then
-    1. Set VL to XLEN.
-4. Else If regs[rs1] > imm, then
-    1. Set VL to regs[rs1] / 2 rounded down.
-5. Otherwise,
-    1. Set VL to regs[rs1].
-6. Set regs[rd] to VL.
 
 Additional Instructions
 =======================
@@ -537,6 +539,10 @@ Add a register gather instruction (aka MV.X)
 
 # Open questions <a name="questions"></a>
 
+Confirmation needed as to whether subvector extraction can be covered by twin predication (it probably can, it is one of the many purposes it is for).
+
+--
+
 What is SUBVL and how does it work
 
 --
@@ -560,3 +566,24 @@ Is MV.X good enough a substitute for swizzle?
 --
 
 Is vectorised srcbase ok as a gather scatter and ok substitute for register stride? 5 dependency registers (reg stride being the 5th) is quite scary
+
+--
+
+Why are integer conversion instructions needed, when the main SV spec covers them by allowing elwidth to be set on both src and dest regs?
+
+--
+
+Why are the SETVL rules so complex? What is the reason, how are loops carried out?
+
+--
+
+With SUBVL (sub vector len) being both a CSR and also part of the 48/64 bit opcode, how does that work?
+
+--
+
+What are the interaction rules when a 48/64 prefix opcode has a rd/rs that already has a Vector Context for either predication or a register?
+
+It would perhaps make sense (and for svlen as well) to make 48/64 isolated and unaffected by VLIW context, with the exception of VL/MVL.
+
+MVL and VL should be modifiable by 64 bit prefix as they are global in nature.
+