simple_v_extension/sv_prefix_proposal.rst

   1 SimpleV Prefix (SVprefix) Proposal v0.3
   2 =======================================
   3
   4 * Copyright (c) Jacob Lifshay, 2019
   5 * Copyright (c) Luke Kenneth Casson Leighton, 2019
   6
   7 This proposal is designed to be able to operate without SVorig, but not to
   8 require the absence of SVorig See Specification_.
   9
  10 .. _Specification: http://libre-riscv.org/simple_v_extension/specification/
  11
  12 .. contents::
  13
  14 Conventions
  15 ===========
  16
  17 Conventions used in this document:
  18
  19 * Bits are numbered starting from 0 at the LSB, so bit 3 is 1 in the integer 8.
  20 * Bit ranges are inclusive on both ends, so 5:3 means bits 5, 4, and 3.
  21 * Operations work on variable-length vectors of sub-vectors up to *VL*
  22   in length, where each sub-vector has a length *svlen*, and *svlen*
  23   elements of type *etype*.
  24 * The actual total number of elements is therefore *svlen* times *VL*.
  25 * When the vectors are stored in registers, all elements are packed so
  26   that there is no padding in-between elements of the same vector.
  27 * The register file itself is thus best viewed as a byte-level SRAM that
  28   is typecast to an array of *etypes*
  29 * The number of bytes in a sub-vector, *svsz*, is the product of *svlen*
  30   and the element size in bytes.
  31
  32 Options
  33 =======
  34
  35 The following partial / full implementation options are possible:
  36
  37 * SVPrefix augments the main Specification_
  38 * SVPregix operates independently, without the main spec VL (and MVL)
  39   CSRs (in any priv level)
  40 * SVPrefix operates independently, without the main spec SUBVL CSRs
  41   (in any priv level)
  42 * SVPrefix has no support for VL (or MVL) overrides in the 64 bit
  43   instruction format (VLtyp=0 as the only legal permitted value)
  44 * SVPrefix has no support for svlen overrides in either the 48 or 64
  45   bit instruction format either (svlen=0 as the only legal permitted value).
  46
  47 All permutations of the above options are permitted, and the UNIX
  48 platform must raise illegal instruction exceptions on implementations
  49 that do not support each option.  For example, an implementation that
  50 has no support for VLtyp that sees an opcode with a nonzero VLtyp must
  51 raise an illegal instruction exception.
  52
  53 Note that SVPrefix (VLtyp and svlen) and the main spec share (modify) the
  54 STATE CSR. P48 and P64 opcodes must **NOT** set VLtyp or svlen inside
  55 loops that also use VL or SUBVL. Doing so will result in undefined
  56 behaviour, as STATE will be affected by doing so.
  57
  58 However, using VLtyp or svlen in standalone operations, or pushing (and
  59 restoring) the contents of the STATE CSR to the stack, or just storing
  60 its contents in a temporary register whilst executing a sequence of P48
  61 or P64 opcodes, is perfectly fine.
  62
  63 If the main Specification_ CSRs are to be supported, the STATE, VL, MVL
  64 and SUBVL CSRs all operate according to the main specification. Under
  65 the options above, hypothetically an implementor could choose not to
  66 support setting of VL, MVL or SUBVL (only allowing them to be set to
  67 a value of 1). Under such circumstances, where *neither* VL/MVL *nor*
  68 SUBVL are supported, STATE would then not be required either.
  69
  70 If however support for SUBVL is to be provided, storing of the sub-vector
  71 offsets and SUBVL itself (and context switching of the same) in the
  72 STATE CSRs are mandatory.
  73
  74 Likewise if support for VL is to be provided, storing of VL, MVL and the
  75 dest and src offsets (and context switching of the same) in the STATE
  76 CSRs are mandatory.
  77
  78
  79 Half-Precision Floating Point (FP16)
  80 ====================================
  81
  82 If the F extension is supported, SVprefix adds support for FP16 in the
  83 base FP instructions by using 10 (H) in the floating-point format field
  84 *fmt* and using 001 (H) in the floating-point load/store *width* field.
  85
  86 Compressed Instructions
  87 =======================
  88
  89 This proposal does not include any prefixed RVC instructions, instead,
  90 it will include 32-bit instructions that are compressed forms of
  91 SVprefix 48-bit instructions, in the same manner that RVC instructions
  92 are compressed forms of RVI instructions. The compressed instructions
  93 will be defined later by considering which 48-bit instructions are the
  94 most common.
  95
  96 48-bit Prefixed Instructions
  97 ============================
  98
  99 All 48-bit prefixed instructions contain a 32-bit "base" instruction as
 100 the last 4 bytes. Since all 32-bit instructions have bits 1:0 set to
 101 11, those bits are reused for additional encoding space in the 48-bit
 102 instructions.
 103
 104 64-bit Prefixed Instructions
 105 ============================
 106
 107 The 48 bit format is further extended with the full 128-bit range on all
 108 source and destination registers, and the option to set both VL and MVL
 109 is provided.
 110
 111 48-bit Instruction Encodings
 112 ============================
 113
 114 In the following table, *Reserved* entries must be zero.  RV32 equivalent
 115 encodings included for side-by-side comparison (and listed below,
 116 separately).
 117
 118 First, bits 17:0:
 119
 120 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
 121 | Encoding      | 17     | 16         | 15         | 14  | 13         | 12          | 11:7 | 6          | 5:0    |
 122 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
 123 | P48-LD-type   | rd[5]  | rs1[5]     | vitp7[6]   | vd  | vs1        | vitp7[5:0]         | 0          | 011111 |
 124 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
 125 | P48-ST-type   |vitp7[6]| rs1[5]     | rs2[5]     | vs2 | vs1        | vitp7[5:0]         | 0          | 011111 |
 126 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
 127 | P48-R-type    | rd[5]  | rs1[5]     | rs2[5]     | vs2 | vs1        | vitp6              | 0          | 011111 |
 128 +---------------+--------+------------+------------+-----+------------+--------------------+------------+--------+
 129 | P48-I-type    | rd[5]  | rs1[5]     | vitp7[6]   | vd  | vs1        | vitp7[5:0]         | 0          | 011111 |
 130 +---------------+--------+------------+------------+-----+------------+--------------------+------------+--------+
 131 | P48-U-type    | rd[5]  | *Reserved* | *Reserved* | vd  | *Reserved* | vitp6              | 0          | 011111 |
 132 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
 133 | P48-FR-type   | rd[5]  | rs1[5]     | rs2[5]     | vs2 | vs1        | *Reserved*  | vtp5 | 0          | 011111 |
 134 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
 135 | P48-FI-type   | rd[5]  | rs1[5]     | vitp7[6]   | vd  | vs1        | vitp7[5:0]         | 0          | 011111 |
 136 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
 137 | P48-FR4-type  | rd[5]  | rs1[5]     | rs2[5]     | vs2 | rs3[5]     | vs3 [#fr4]_ | vtp5 | 0          | 011111 |
 138 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
 139
 140 .. [#fr4] Only vs2 and vs3 are included in the P48-FR4-type encoding
 141           because there is not enough space for vs1 as well, and because
 142           it is more useful to have a scalar argument for each of the
 143           multiplication and addition portions of fmadd than to have
 144           two scalars on the multiplication portion.
 145
 146 Table showing correspondance between P48-*-type and RV32-*-type.
 147 These are bits 47:18 (RV32 shifted up by 16 bits):
 148
 149 +---------------+---------------+
 150 | Encoding      | 47:18         |
 151 +---------------+---------------+
 152 | RV32 Encoding | 31:2          |
 153 +---------------+---------------+
 154 | P48-LD-type   | RV32-I-type   |
 155 +---------------+---------------+
 156 | P48-ST-type   | RV32-S-Type   |
 157 +---------------+---------------+
 158 | P48-R-type    | RV32-R-Type   |
 159 +---------------+---------------+
 160 | P48-I-type    | RV32-I-Type   |
 161 +---------------+---------------+
 162 | P48-U-type    | RV32-U-Type   |
 163 +---------------+---------------+
 164 | P48-FR-type   | RV32-FR-Type  |
 165 +---------------+---------------+
 166 | P48-FI-type   | RV32-I-Type   |
 167 +---------------+---------------+
 168 | P48-FR4-type  | RV32-FR4-type |
 169 +---------------+---------------+
 170
 171 Table showing Standard RV32 encodings:
 172
 173 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+
 174 | Encoding      | 31:27       | 26:25 | 24:20    | 19:15    | 14:12  | 11:7     | 6:2    | 1:0    |
 175 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+
 176 | RV32-R-type   +    funct7           + rs2[4:0] + rs1[4:0] + funct3 | rd[4:0]  + opcode + 0b11   |
 177 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+
 178 | RV32-S-type   + imm[11:5]           + rs2[4:0] + rs1[4:0] + funct3 | imm[4:0] + opcode + 0b11   |
 179 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+
 180 | RV32-I-type   + imm[11:0]                      + rs1[4:0] + funct3 | rd[4:0]  + opcode + 0b11   |
 181 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+
 182 | RV32-U-type   + imm[31:12]                                         | rd[4:0]  + opcode + 0b11   |
 183 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+
 184 | RV32-FR4-type + rs3[4:0]    + fmt   + rs2[4:0] + rs1[4:0] + funct3 | rd[4:0]  + opcode + 0b11   |
 185 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+
 186 | RV32-FR-type  + funct5      + fmt   + rs2[4:0] + rs1[4:0] + rm     | rd[4:0]  + opcode + 0b11   |
 187 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+
 188
 189 64-bit Instruction Encodings
 190 ============================
 191
 192 Where in the 48 bit format the prefix is "0b0011111" in bits 0 to 6,
 193 this is now set to "0b0111111".
 194
 195 +---------------+---------------+--------------+-----------+
 196 | 63:48         | 47:18         | 17:7         | 6:0       |
 197 +---------------+---------------+--------------+-----------+
 198 | 64 bit prefix | RV32[31:3]    | P48[17:7]    | 0b0111111 |
 199 +---------------+---------------+--------------+-----------+
 200
 201 * The 64 bit prefix format is below
 202 * Bits 18 to 47 contain bits 3 to 31 of a standard RV32 format
 203 * Bits 7 to 17 contain bits 7 through 17 of the P48 format
 204 * Bits 0 to 6 contain the standard RV 64-bit prefix 0b0111111
 205
 206 64 bit prefix format:
 207
 208 +--------------+-------+--------+--------+--------+--------+
 209 | Encoding     | 63    | 62     | 61     | 60     | 59:48  |
 210 +--------------+-------+--------+--------+--------+--------+
 211 | P64-LD-type  | rd[6] | rs1[6] |        |        | VLtyp  |
 212 +--------------+-------+--------+--------+--------+--------+
 213 | P64-ST-type  |       | rs1[6] | rs2[6] |        | VLtyp  |
 214 +--------------+-------+--------+--------+--------+--------+
 215 | P64-R-type   | rd[6] | rs1[6] | rs2[6] |        | VLtyp  |
 216 +--------------+-------+--------+--------+--------+--------+
 217 | P64-I-type   | rd[6] | rs1[6] |        |        | VLtyp  |
 218 +--------------+-------+--------+--------+--------+--------+
 219 | P64-U-type   | rd[6] |        |        |        | VLtyp  |
 220 +--------------+-------+--------+--------+--------+--------+
 221 | P64-FR-type  |       | rs1[6] | rs2[6] |        | VLtyp  |
 222 +--------------+-------+--------+--------+--------+--------+
 223 | P64-FI-type  | rd[6] | rs1[6] | rs2[6] |        | VLtyp  |
 224 +--------------+-------+--------+--------+--------+--------+
 225 | P64-FR4-type | rd[6] | rs1[6] | rs2[6] | rs3[6] | VLtyp  |
 226 +--------------+-------+--------+--------+--------+--------+
 227
 228 The extra bit for src and dest registers provides the full range of
 229 up to 128 registers, when combined with the extra bit from the 48 bit
 230 prefix as well.  VLtyp encodes how (whether) to set VL and MAXVL.
 231
 232 VLtyp field encoding
 233 ====================
 234
 235 NOTE: VL and MVL below are modified (potentially damaging) and so is
 236 the STATE CSR. It is the responsibility of the programmer to ensure that
 237 modifications to STATE do not compromise loops or VLIW Group opetations,
 238 by saving and restoring the STATE CSR (if needed).
 239
 240 +-----------+-------------+--------------+----------+----------------------+
 241 | VLtyp[11] | VLtyp[10:6] | VLtyp[5:1]   | VLtyp[0] | comment              |
 242 +-----------+-------------+--------------+----------+----------------------+
 243 | 0         |  000000     | 00000        |  0       | no change to VL/MVL  |
 244 +-----------+-------------+--------------+----------+----------------------+
 245 | 0         |  VLdest     | VLEN         |  vlt     | VL imm/reg mode (vlt)|
 246 +-----------+-------------+--------------+----------+----------------------+
 247 | 1         |  VLdest     | MVL+VL-immed | 0        | MVL+VL immed mode    |
 248 +-----------+-------------+--------------+----------+----------------------+
 249 | 1         |  VLdest     |  MVL-immed   | 1        | MVL immed mode       |
 250 +-----------+-------------+--------------+----------+----------------------+
 251
 252 Note: when VLtyp is all zeros, neither VL nor MVL are changed.
 253
 254 Just as in the VLIW format, when bit 11 of VLtyp is zero:
 255
 256 * if vlt is zero, bits 1 to 5 specify the VLEN as a 5 bit immediate
 257   (offset by 1: 0b00000 represents VL=1, 0b00001 represents VL=2 etc.)
 258 * if vlt is 1, bits 1 to 5 specify the scalar (RV standard) register
 259   from which VL is set.  x0 is not permitted
 260 * VL goes into the scalar register VLdest (if VLdest is not x0)
 261
 262 When bit 11 of VLtype is 1:
 263
 264 * if VLtyp[0] is zero, both MAXVL and VL are set to (imm+1).  The same
 265   value goes into the scalar register VLdest (if VLdest is not x0)
 266 * if VLtyp[0] is 1, MAXVL is set to (imm+1).
 267   VL will be truncated to within the new range (if VL was greater
 268   than the new MAXVL).  The new VL goes into the scalar register VLdest
 269   (if VLdest is not x0).
 270
 271 This gives the option to set up VL in a "loop mode" (VLtype[11]=0) or
 272 in a "one-off" mode (VLtype[11]=1) which sets both MVL and VL to the
 273 same immediate value.  This may be most useful for one-off Vectorised
 274 operations such as LOAD-MULTI / STORE-MULTI, for saving and restoration
 275 of large batches of registers in context-switches or function calls.
 276
 277 Note that VLtyp's VL and MVL are the same as the main Specification_
 278 VL or MVL, and that loops will also alter srcoffs and destoffs. It is
 279 the programmer's responsibility to ensure that STATE is not compromised
 280 (e.g saved to a temp reg or to the stack).
 281
 282 Furthermore, the execution order and exception handling must be exactly
 283 the same as in the main spec.
 284
 285 vs#/vd Fields' Encoding
 286 =======================
 287
 288 +--------+----------+----------------------------------------------------------+
 289 | vs#/vd | Mnemonic | Meaning                                                  |
 290 +========+==========+==========================================================+
 291 | 0      | S        | the rs#/rd field specifies a scalar (single sub-vector); |
 292 |        |          | the rs#/rd field is zero-extended to get the actual      |
 293 |        |          | 7-bit register number                                    |
 294 +--------+----------+----------------------------------------------------------+
 295 | 1      | V        | the rs#/rd field specifies a vector; the rs#/rd field is |
 296 |        |          | decoded using the `Vector Register Number Encoding`_ to  |
 297 |        |          | get the actual 7-bit register number                     |
 298 +--------+----------+----------------------------------------------------------+
 299
 300 If a vs#/vd field is not present, it is as if it was present with a value that
 301 is the bitwise-or of all present vs#/vd fields.
 302
 303 * scalar register numbers do NOT increment when allocated in the
 304   hardware for-loop.  the same scalar register number is handed
 305   to every ALU.
 306
 307 * vector register numbers *DO* increase when allocated in the
 308   hardware for-loop.  sequentially-increasing register data
 309   is handed to sequential ALUs.
 310
 311 Vector Register Number Encoding
 312 ===============================
 313
 314 For the 48 bit format, when vs#/vd is 1, the actual 7-bit register number
 315 is derived from the corresponding 6-bit rs#/rd field:
 316
 317 +---------------------------------+
 318 | Actual 7-bit register number    |
 319 +===========+=============+=======+
 320 | Bit 6     | Bits 5:1    | Bit 0 |
 321 +-----------+-------------+-------+
 322 | rs#/rd[0] | rs#/rd[5:1] | 0     |
 323 +-----------+-------------+-------+
 324
 325 For the 64 bit format, the 7 bit register is constructed from the 7 bit
 326 fields: bits 0 to 4 from the 32 bit RV Standard format, bit 5 from the 48
 327 bit prefix and bit 6 from the 64 bit prefix.  Thus in the 64 bit format
 328 the full range of up to 128 registers is directly available. This for
 329 both when either scalar or vector mode is set.
 330
 331 Load/Store Kind (lsk) Field Encoding
 332 ====================================
 333
 334 +--------+-----+--------------------------------------------------------------------------------+
 335 | vd/vs2 | vs1 | Meaning                                                                        |
 336 +========+=====+================================================================================+
 337 | 0      | 0   | srcbase is scalar, LD/ST is pure scalar.                                       |
 338 +--------+-----+--------------------------------------------------------------------------------+
 339 | 1      | 0   | srcbase is scalar, LD/ST is unit strided                                       |
 340 +--------+-----+--------------------------------------------------------------------------------+
 341 | 0      | 1   | srcbase is a vector (gather/scatter aka array of srcbases). VSPLAT and VSELECT |
 342 +--------+-----+--------------------------------------------------------------------------------+
 343 | 1      | 1   | srcbase is a vector, LD/ST is a full vector LD/ST.                             |
 344 +--------+-----+--------------------------------------------------------------------------------+
 345
 346 Notes:
 347
 348 * A register strided LD/ST would require *5* registers. srcbase, vd/vs2,
 349   predicate 1, predicate 2 and the stride register.
 350 * Complex strides may all be done with a general purpose vector of srcbases.
 351 * Twin predication may be used even when vd/vs1 is a scalar, to give
 352   VSPLAT and VSELECT, because the hardware loop ends on the first occurrence
 353   of a 1 in the predicate when a predicate is applied to a scalar.
 354 * Full vectorised gather/scatter is enabled when both registers are
 355   marked as vectorised, however unlike e.g Intel AVX512, twin predication
 356   can be applied.
 357
 358 Open question: RVV overloads the width field of LOAD-FP/STORE-FP
 359 using the bit 2 to indicate additional interpretation of the 11 bit
 360 immediate. Should this be considered?
 361
 362
 363 Sub-Vector Length (svlen) Field Encoding
 364 ========================================
 365
 366 NOTE: svlen is the same as the main spec SUBVL, and modifies the STATE
 367 CSR. The same caveats apply to svlen as do to SUBVL.
 368
 369 Bitwidth, from VL's perspective, is a multiple of the elwidth times svlen.
 370 So within each loop of VL there are svlen sub-elements of elwidth in size,
 371 just like in a SIMD architecture. When svlen is set to 0b00 (indicating
 372 svlen=1) no such SIMD-like behaviour exists and the subvectoring is
 373 disabled.
 374
 375 Predicate bits do not apply to the individual sub-vector elements, they
 376 apply to the entire subvector group. This saves instructions on setup
 377 of the predicate.
 378
 379 +----------------+-------+
 380 | svlen Encoding | Value |
 381 +================+=======+
 382 | 00             | SUBVL |
 383 +----------------+-------+
 384 | 01             | 2     |
 385 +----------------+-------+
 386 | 10             | 3     |
 387 +----------------+-------+
 388 | 11             | 4     |
 389 +----------------+-------+
 390
 391 In independent standalone implementations that do not implement the
 392 main specification, the value of SUBVL in the above table (svtyp=0b00)
 393 is set to 1, such that svlen is also 1.
 394
 395 Behaviour of operations that set svlen are identical to those of the
 396 main spec. See section on VLtyp, above.
 397
 398 Predication (pred) Field Encoding
 399 =================================
 400
 401 +------+------------+--------------------+----------------------------------------+
 402 | pred | Mnemonic   | Predicate Register | Meaning                                |
 403 +======+============+====================+========================================+
 404 | 000  | *None*     | *None*             | The instruction is unpredicated        |
 405 +------+------------+--------------------+----------------------------------------+
 406 | 001  | *Reserved* | *Reserved*         |                                        |
 407 +------+------------+--------------------+----------------------------------------+
 408 | 010  | !x9        | x9 (s1)            | execute vector op[0..i] on x9[i] == 0  |
 409 +------+------------+                    +----------------------------------------+
 410 | 011  | x9         |                    | execute vector op[0..i] on x9[i] == 1  |
 411 +------+------------+--------------------+----------------------------------------+
 412 | 100  | !x10       | x10 (a0)           | execute vector op[0..i] on x10[i] == 0 |
 413 +------+------------+                    +----------------------------------------+
 414 | 101  | x10        |                    | execute vector op[0..i] on x10[i] == 1 |
 415 +------+------------+--------------------+----------------------------------------+
 416 | 110  | !x11       | x11 (a1)           | execute vector op[0..i] on x11[i] == 0 |
 417 +------+------------+                    +----------------------------------------+
 418 | 111  | x11        |                    | execute vector op[0..i] on x11[i] == 1 |
 419 +------+------------+--------------------+----------------------------------------+
 420
 421 Twin-predication (tpred) Field Encoding
 422 =======================================
 423
 424 +-------+------------+--------------------+----------------------------------------------+
 425 | tpred | Mnemonic   | Predicate Register | Meaning                                      |
 426 +=======+============+====================+==============================================+
 427 | 000   | *None*     | *None*             | The instruction is unpredicated              |
 428 +-------+------------+--------------------+----------------------------------------------+
 429 | 001   | x9,off     | src=x9, dest=none  | src[0..i] uses x9[i], dest unpredicated      |
 430 +-------+------------+                    +----------------------------------------------+
 431 | 010   | off,x10    | src=none, dest=x10 | dest[0..i] uses x10[i], src unpredicated     |
 432 +-------+------------+                    +----------------------------------------------+
 433 | 011   | x9,10      | src=x9, dest=x10   | src[0..i] uses x9[i], dest[0..i] uses x10[i] |
 434 +-------+------------+--------------------+----------------------------------------------+
 435 | 100   | *None*     | *RESERVED*         | Instruction is unpredicated (TBD)            |
 436 +-------+------------+--------------------+----------------------------------------------+
 437 | 101   | !x9,off    | src=!x9, dest=none |                                              |
 438 +-------+------------+                    +----------------------------------------------+
 439 | 110   | off,!x10   | src=none, dest=!x10|                                              |
 440 +-------+------------+                    +----------------------------------------------+
 441 | 111   | !x9,!x10   | src=!x9, dest=!x10 |                                              |
 442 +-------+------------+--------------------+----------------------------------------------+
 443
 444 Integer Element Type (itype) Field Encoding
 445 ===========================================
 446
 447 +------------+-------+--------------+--------------+-----------------+-------------------+
 448 | Signedness | itype | Element Type | Mnemonic in  | Mnemonic in FP  | Meaning (INT may  |
 449 | [#sgn_def]_|       |              | Integer      | Instructions    | be un/signed, FP  |
 450 | [#sgn_def]_|       |              | Instructions | (such as fmv.x) | just re-sized     |
 451 +============+=======+==============+==============+=================+===================+
 452 | Unsigned   | 01    | u8           | BU           | BU              | Unsigned 8-bit    |
 453 |            +-------+--------------+--------------+-----------------+-------------------+
 454 |            | 10    | u16          | HU           | HU              | Unsigned 16-bit   |
 455 |            +-------+--------------+--------------+-----------------+-------------------+
 456 |            | 11    | u32          | WU           | WU              | Unsigned 32-bit   |
 457 |            +-------+--------------+--------------+-----------------+-------------------+
 458 |            | 00    | uXLEN        | WU/DU/QU     | WU/LU/TU        | Unsigned XLEN-bit |
 459 +------------+-------+--------------+--------------+-----------------+-------------------+
 460 | Signed     | 01    | i8           | BS           | BS              | Signed 8-bit      |
 461 |            +-------+--------------+--------------+-----------------+-------------------+
 462 |            | 10    | i16          | HS           | HS              | Signed 16-bit     |
 463 |            +-------+--------------+--------------+-----------------+-------------------+
 464 |            | 11    | i32          | W            | W               | Signed 32-bit     |
 465 |            +-------+--------------+--------------+-----------------+-------------------+
 466 |            | 00    | iXLEN        | W/D/Q        | W/L/T           | Signed XLEN-bit   |
 467 +------------+-------+--------------+--------------+-----------------+-------------------+
 468
 469 .. [#sgn_def] Signedness is defined in `Signedness Decision Procedure`_
 470
 471 Note: vector mode is effectively a type-cast of the register file
 472 as if it was a sequential array being typecast to typedef itype[]
 473 (c syntax).  The starting point of the "typecast" is the vector
 474 register rs#/rd.
 475
 476 Example: if itype=0b10 (u16), and rd is set to "vector", and
 477 VL is set to 4, the 64-bit register at rd is subdivided into
 478 *FOUR* 16-bit destination elements.  It is *NOT* four
 479 separate 64-bit destination registers (rd+0, rd+1, rd+2, rd+3)
 480 that are sign-extended from the source width size out to 64-bit,
 481 because that is itype=0b00 (uXLEN).
 482
 483 Note also: changing elwidth creates packed elements that, depending on
 484 VL, may create vectors that do not fit perfectly onto XLEN sized registry
 485 file bit-boundaries. This does NOT result in the destruction of the MSBs
 486 of the last register written to at the end of a VL loop. More details
 487 on how to handle this are described in the main Specification_.
 488
 489 Signedness Decision Procedure
 490 =============================
 491
 492 1. If the opcode field is either OP or OP-IMM, then
 493     1. Signedness is Unsigned.
 494 2. If the opcode field is either OP-32 or OP-IMM-32, then
 495     1. Signedness is Signed.
 496 3. If Signedness is encoded in a field of the base instruction, [#sign_enc]_ then
 497     1. Signedness uses the encoded value.
 498 4. Otherwise,
 499     1. Signedness is Unsigned.
 500
 501 .. [#sign_enc] Like in fcvt.d.l[u], but unlike in fmv.x.w,
 502                since there is no fmv.x.wu
 503
 504 Vector Type and Predication 5-bit (vtp5) Field Encoding
 505 =========================================================
 506
 507 In the following table, X denotes a wildcard that is 0 or 1 and can be
 508 a different value for every occurrence.
 509
 510 +-------+-----------+-----------+
 511 | vtp5  | pred      | svlen     |
 512 +=======+===========+===========+
 513 | 1XXXX | vtp5[4:2] | vtp5[1:0] |
 514 +-------+           |           |
 515 | 01XXX |           |           |
 516 +-------+           |           |
 517 | 000XX |           |           |
 518 +-------+-----------+-----------+
 519 | 001XX | *Reserved*            |
 520 +-------+-----------------------+
 521
 522 Vector Integer Type and Predication 6-bit (vitp6) Field Encoding
 523 =================================================================
 524
 525 In the following table, X denotes a wildcard that is 0 or 1 and can be a
 526 different value for every occurrence.
 527
 528 +--------+------------+---------+------------+------------+
 529 | vitp6  | itype      | pred[2] | pred[0:1]  | svlen      |
 530 +========+============+=========+============+============+
 531 | XX1XXX | vitp6[5:4] | 0       | vitp6[3:2] | vitp6[1:0] |
 532 +--------+            |         |            |            |
 533 | XX00XX |            |         |            |            |
 534 +--------+------------+---------+------------+------------+
 535 | XX01XX | *Reserved*                                     |
 536 +--------+------------------------------------------------+
 537
 538 vitp7 field: only tpred
 539
 540 +---------+------------+----------+-------------+------------+
 541 | vitp7   | itype      | tpred[2] | tpred[0:1]  | svlen      |
 542 +=========+============+==========+=============+============+
 543 | XXXXXXX | vitp7[5:4] | vitp7[6] | vitp7[3:2]  | vitp7[1:0] |
 544 +---------+------------+----------+-------------+------------+
 545
 546 48-bit Instruction Encoding Decision Procedure
 547 ==============================================
 548
 549 In the following decision procedure, *Reserved* means that there is not
 550 yet a defined 48-bit instruction encoding for the base instruction.
 551
 552 1. If the base instruction is a load instruction, then
 553     a. If the base instruction is an I-type instruction, then
 554         1. The encoding is P48-LD-type.
 555     b. Otherwise
 556         1. The encoding is *Reserved*.
 557 2. If the base instruction is a store instruction, then
 558     a. If the base instruction is an S-type instruction, then
 559         1. The encoding is P48-ST-type.
 560     b. Otherwise
 561         1. The encoding is *Reserved*.
 562 3. If the base instruction is a SYSTEM instruction, then
 563     a. The encoding is *Reserved*.
 564 4. If the base instruction is an integer instruction, then
 565     a. If the base instruction is an R-type instruction, then
 566         1. The encoding is P48-R-type.
 567     b. If the base instruction is an I-type instruction, then
 568         1. The encoding is P48-I-type.
 569     c. If the base instruction is an S-type instruction, then
 570         1. The encoding is *Reserved*.
 571     d. If the base instruction is an B-type instruction, then
 572         1. The encoding is *Reserved*.
 573     e. If the base instruction is an U-type instruction, then
 574         1. The encoding is P48-U-type.
 575     f. If the base instruction is an J-type instruction, then
 576         1. The encoding is *Reserved*.
 577     g. Otherwise
 578         1. The encoding is *Reserved*.
 579 5. If the base instruction is a floating-point instruction, then
 580     a. If the base instruction is an R-type instruction, then
 581         1. The encoding is P48-FR-type.
 582     b. If the base instruction is an I-type instruction, then
 583         1. The encoding is P48-FI-type.
 584     c. If the base instruction is an S-type instruction, then
 585         1. The encoding is *Reserved*.
 586     d. If the base instruction is an B-type instruction, then
 587         1. The encoding is *Reserved*.
 588     e. If the base instruction is an U-type instruction, then
 589         1. The encoding is *Reserved*.
 590     f. If the base instruction is an J-type instruction, then
 591         1. The encoding is *Reserved*.
 592     g. If the base instruction is an R4-type instruction, then
 593         1. The encoding is P48-FR4-type.
 594     h. Otherwise
 595         1. The encoding is *Reserved*.
 596 6. Otherwise
 597     a. The encoding is *Reserved*.
 598
 599 CSR Registers
 600 =============
 601
 602 CSRs are the same as in the main Specification_, if associated
 603 functionality is implemented. They have the exact same meaning as in
 604 the main specification.
 605
 606 * VL
 607 * MVL
 608 * STATE
 609 * SUBVL
 610
 611 Associated SET and GET on the CSRs is exactly as in the main spec as well
 612 (including CSRRWI and CSRRW differences).
 613
 614 Note that if all of VL/MVL, SUBVL, VLtyp and svlen are all chosen by an
 615 implementor not to be implemented, the STATE CSR is not required.
 616
 617 However if partial functionality is implemented, the unimplemented bits
 618 in STATE must be zero, and, in the UNIX Platform, an illegal exception
 619 **MUST** be raised if unsupported bits are written to.
 620
 621 Additional Instructions
 622 =======================
 623
 624 Add instructions to convert between integer types.
 625
 626 Add instructions to `swizzle`_ elements in sub-vectors. Note that the sub-vector
 627 lengths of the source and destination won't necessarily match.
 628
 629 .. _swizzle: https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Swizzling
 630
 631 Add instructions to transpose (2-4)x(2-4) element matrices.
 632
 633 Add instructions to insert or extract a sub-vector from a vector, with
 634 the index allowed to be both immediate and from a register (*immediate
 635 can be covered by twin-predication, register might be, by virtue of
 636 predicates being registers*)
 637
 638 Add a register gather instruction (aka MV.X: regfile[rd] =
 639 regfile[regfile[rs1]])
 640
 641 questions
 642 =========
 643
 644 Confirmation needed as to whether subvector extraction can be covered
 645 by twin predication (it probably can, it is one of the many purposes it
 646 is for).
 647
 648 --
 649
 650 What is SUBVL and how does it work
 651
 652 --
 653
 654 SVorig goes to a lot of effort to make VL 1<= MAXVL and MAXVL 1..64
 655 where both CSRs may be stored internally in only 6 bits.
 656
 657 Thus, CSRRWI can reach 1..32 for VL and MAXVL.
 658
 659 In addition, setting a hardware loop to zero turning instructions into
 660 NOPs, um, just branch over them, to start the first loop at the end,
 661 on the test for loop variable being zero, a la c "while do" instead of
 662 "do while".
 663
 664 Or, does it not matter that VL only goes up to 31 on a CSRRWI, and that
 665 it only goes to a max of 63 rather than 64?
 666
 667 --
 668
 669 Should these questions be moved to Discussion subpage
 670
 671 --
 672
 673 Is MV.X good enough a substitute for swizzle?
 674
 675 --
 676
 677 Is vectorised srcbase ok as a gather scatter and ok substitute for
 678 register stride? 5 dependency registers (reg stride being the 5th)
 679 is quite scary
 680
 681 --
 682
 683 Why are integer conversion instructions needed, when the main SV spec
 684 covers them by allowing elwidth to be set on both src and dest regs?
 685
 686 --
 687
 688 Why are the SETVL rules so complex? What is the reason, how are loops
 689 carried out?
 690
 691 --
 692
 693 With SUBVL (sub vector len) being both a CSR and also part of the 48/64
 694 bit opcode, how does that work?
 695
 696 --
 697
 698 What are the interaction rules when a 48/64 prefix opcode has a rd/rs
 699 that already has a Vector Context for either predication or a register?
 700
 701 It would perhaps make sense (and for svlen as well) to make 48/64 isolated
 702 and unaffected by VLIW context, with the exception of VL/MVL.
 703
 704 MVL and VL should be modifiable by 64 bit prefix as they are global
 705 in nature.
 706
 707 Possible solution, svlen and VLtyp allowed to share STATE CSR however
 708 programmer becomes responsible for push and pop of state during use of
 709 a sequence of P48 and P64 ops.
 710
 711 --
 712
 713 Can bit 60 of P64 be put to use (in all but the FR4 case)?
 714