1 # Simple-V (Parallelism Extension Proposal) Specification
3 * Copyright (C) 2017, 2018, 2019 Luke Kenneth Casson Leighton
5 * Last edited: 21 jun 2019
6 * Ancillary resource: [[opcodes]] [[sv_prefix_proposal]]
17 * The RISC-V Founders, without whom this all would not be possible.
21 # Summary and Background: Rationale
23 Simple-V is a uniform parallelism API for RISC-V hardware that has several
24 unplanned side-effects including code-size reduction, expansion of
25 HINT space and more. The reason for
26 creating it is to provide a manageable way to turn a pre-existing design
27 into a parallel one, in a step-by-step incremental fashion, without adding any new opcodes, thus allowing
28 the implementor to focus on adding hardware where it is needed and necessary.
29 The primary target is for mobile-class 3D GPUs and VPUs, with secondary
30 goals being to reduce executable size (by extending the effectiveness of RV opcodes, RVC in particular) and reduce context-switch latency.
32 Critically: **No new instructions are added**. The parallelism (if any
33 is implemented) is implicitly added by tagging *standard* scalar registers
34 for redirection. When such a tagged register is used in any instruction,
35 it indicates that the PC shall **not** be incremented; instead a loop
36 is activated where *multiple* instructions are issued to the pipeline
37 (as determined by a length CSR), with contiguously incrementing register
38 numbers starting from the tagged register. When the last "element"
39 has been reached, only then is the PC permitted to move on. Thus
40 Simple-V effectively sits (slots) *in between* the instruction decode phase
43 The barrier to entry with SV is therefore very low. The minimum
44 compliant implementation is software-emulation (traps), requiring
45 only the CSRs and CSR tables, and that an exception be thrown if an
46 instruction's registers are detected to have been tagged. The looping
47 that would otherwise be done in hardware is thus carried out in software,
48 instead. Whilst much slower, it is "compliant" with the SV specification,
49 and may be suited for implementation in RV32E and also in situations
50 where the implementor wishes to focus on certain aspects of SV, without
51 unnecessary time and resources into the silicon, whilst also conforming
52 strictly with the API. A good area to punt to software would be the
53 polymorphic element width capability for example.
55 Hardware Parallelism, if any, is therefore added at the implementor's
56 discretion to turn what would otherwise be a sequential loop into a
59 To emphasise that clearly: Simple-V (SV) is *not*:
63 * A Vectorisation Microarchitecture
64 * A microarchitecture of any specific kind
65 * A mandary parallel processor microarchitecture of any kind
66 * A supercomputer extension
68 SV does **not** tell implementors how or even if they should implement
69 parallelism: it is a hardware "API" (Application Programming Interface)
70 that, if implemented, presents a uniform and consistent way to *express*
71 parallelism, at the same time leaving the choice of if, how, how much,
72 when and whether to parallelise operations **entirely to the implementor**.
76 The principle of SV is as follows:
78 * Standard RV instructions are "prefixed" (extended) through a 48/64
79 bit format (single instruction option) or a variable
80 length VLIW-like prefix (multi or "grouped" option).
81 * The prefix(es) indicate which registers are "tagged" as
82 "vectorised". Predicates can also be added, and element widths
83 overridden on any src or dest register.
84 * A "Vector Length" CSR is set, indicating the span of any future
85 "parallel" operations.
86 * If any operation (a **scalar** standard RV opcode) uses a register
87 that has been so "marked" ("tagged"), a hardware "macro-unrolling loop"
88 is activated, of length VL, that effectively issues **multiple**
89 identical instructions using contiguous sequentially-incrementing
90 register numbers, based on the "tags".
91 * **Whether they be executed sequentially or in parallel or a
92 mixture of both or punted to software-emulation in a trap handler
93 is entirely up to the implementor**.
95 In this way an entire scalar algorithm may be vectorised with
96 the minimum of modification to the hardware and to compiler toolchains.
98 To reiterate: **There are *no* new opcodes**. The scheme works *entirely*
99 on hidden context that augments *scalar* RISCV instructions.
101 # CSRs <a name="csrs"></a>
103 * An optional "reshaping" CSR key-value table which remaps from a 1D
104 linear shape to 2D or 3D, including full transposition.
106 There are five additional CSRs, available in any privilege level:
108 * MVL (the Maximum Vector Length)
109 * VL (which has different characteristics from standard CSRs)
110 * SUBVL (effectively a kind of SIMD)
111 * STATE (containing copies of MVL, VL and SUBVL as well as context information)
112 * PCVLIW (the current operation being executed within a VLIW Group)
114 For User Mode there are the following CSRs:
116 * uePCVLIW (a copy of the sub-execution Program Counter, that is relative
117 to the start of the current VLIW Group, set on a trap).
118 * ueSTATE (useful for saving and restoring during context switch,
119 and for providing fast transitions)
121 There are also two additional CSRs for Supervisor-Mode:
126 And likewise for M-Mode:
131 The u/m/s CSRs are treated and handled exactly like their (x)epc
132 equivalents. On entry to a privilege level, the contents of its (x)eSTATE
133 and (x)ePCVLIW CSRs are copied into STATE and PCVLIW respectively, and
134 on exit from a priv level the STATE and PCVLIW CSRs are copied to the
135 exited priv level's corresponding CSRs.
137 Thus for example, a User Mode trap will end up swapping STATE and ueSTATE
138 (on both entry and exit), allowing User Mode traps to have their own
139 Vectorisation Context set up, separated from and unaffected by normal
142 Likewise, Supervisor Mode may perform context-switches, safe in the
143 knowledge that its Vectorisation State is unaffected by User Mode.
145 For this to work, the (x)eSTATE CSR must be saved onto the stack by the
146 trap, just like (x)epc, before modifying the trap atomicity flag (x)ie.
148 The access pattern for these groups of CSRs in each mode follows the
149 same pattern for other CSRs that have M-Mode and S-Mode "mirrors":
151 * In M-Mode, the S-Mode and U-Mode CSRs are separate and distinct.
152 * In S-Mode, accessing and changing of the M-Mode CSRs is transparently
154 to changing the S-Mode CSRs. Accessing and changing the U-Mode
156 * In U-Mode, accessing and changing of the S-Mode and U-Mode CSRs
159 In M-Mode, only the M-Mode CSRs are in effect, i.e. it is only the
160 M-Mode MVL, the M-Mode STATE and so on that influences the processor
161 behaviour. Likewise for S-Mode, and likewise for U-Mode.
163 This has the interesting benefit of allowing M-Mode (or S-Mode) to be set
164 up, for context-switching to take place, and, on return back to the higher
165 privileged mode, the CSRs of that mode will be exactly as they were.
166 Thus, it becomes possible for example to set up CSRs suited best to aiding
167 and assisting low-latency fast context-switching *once and only once*
168 (for example at boot time), without the need for re-initialising the
169 CSRs needed to do so.
171 Another interesting side effect of separate S Mode CSRs is that
172 Vectorised saving of the entire register file to the stack is a single
173 instruction (accidental provision of LOAD-MULTI semantics). If the
174 SVPrefix P64-LD-type format is used, LOAD-MULTI may even be done with a
175 single standalone 64 bit opcode (P64 may set up both VL and MVL from an
176 immediate field). It can even be predicated, which opens up some very
177 interesting possibilities.
179 The (x)EPCVLIW CSRs must be treated exactly like their corresponding (x)epc
180 equivalents. See VLIW section for details.
182 ## MAXVECTORLENGTH (MVL) <a name="mvl" />
184 MAXVECTORLENGTH is the same concept as MVL in RVV, except that it
185 is variable length and may be dynamically set. MVL is
186 however limited to the regfile bitwidth XLEN (1-32 for RV32,
187 1-64 for RV64 and so on).
189 The reason for setting this limit is so that predication registers, when
190 marked as such, may fit into a single register as opposed to fanning
191 out over several registers. This keeps the hardware implementation a
194 The other important factor to note is that the actual MVL is internally
195 stored **offset by one**, so that it can fit into only 6 bits (for RV64)
196 and still cover a range up to XLEN bits. Attempts to set MVL to zero will
197 return an exception. This is expressed more clearly in the "pseudocode"
198 section, where there are subtle differences between CSRRW and CSRRWI.
200 ## Vector Length (VL) <a name="vl" />
202 VSETVL is slightly different from RVV. Similar to RVV, VL is set to be within
203 the range 1 <= VL <= MVL (where MVL in turn is limited to 1 <= MVL <= XLEN)
205 VL = rd = MIN(vlen, MVL)
207 where 1 <= MVL <= XLEN
209 However just like MVL it is important to note that the range for VL has
210 subtle design implications, covered in the "CSR pseudocode" section
212 The fixed (specific) setting of VL allows vector LOAD/STORE to be used
213 to switch the entire bank of registers using a single instruction (see
214 Appendix, "Context Switch Example"). The reason for limiting VL to XLEN
215 is down to the fact that predication bits fit into a single register of
218 The second and most important change is that, within the limits set by
219 MVL, the value passed in **must** be set in VL (and in the
220 destination register).
222 This has implication for the microarchitecture, as VL is required to be
223 set (limits from MVL notwithstanding) to the actual value
224 requested. RVV has the option to set VL to an arbitrary value that suits
225 the conditions and the micro-architecture: SV does *not* permit this.
227 The reason is so that if SV is to be used for a context-switch or as a
228 substitute for LOAD/STORE-Multiple, the operation can be done with only
229 2-3 instructions (setup of the CSRs, VSETVL x0, x0, #{regfilelen-1},
230 single LD/ST operation). If VL does *not* get set to the register file
231 length when VSETVL is called, then a software-loop would be needed.
232 To avoid this need, VL *must* be set to exactly what is requested
233 (limits notwithstanding).
235 Therefore, in turn, unlike RVV, implementors *must* provide
236 pseudo-parallelism (using sequential loops in hardware) if actual
237 hardware-parallelism in the ALUs is not deployed. A hybrid is also
238 permitted (as used in Broadcom's VideoCore-IV) however this must be
239 *entirely* transparent to the ISA.
241 The third change is that VSETVL is implemented as a CSR, where the
242 behaviour of CSRRW (and CSRRWI) must be changed to specifically store
243 the *new* value in the destination register, **not** the old value.
244 Where context-load/save is to be implemented in the usual fashion
245 by using a single CSRRW instruction to obtain the old value, the
246 *secondary* CSR must be used (STATE). This CSR by contrast behaves
247 exactly as standard CSRs, and contains more than just VL.
249 One interesting side-effect of using CSRRWI to set VL is that this
250 may be done with a single instruction, useful particularly for a
251 context-load/save. There are however limitations: CSRWI's immediate
252 is limited to 0-31 (representing VL=1-32).
254 Note that when VL is set to 1, vector operations cease (but not subvector
255 operations: that requires setting SUBVL=1) the hardware loop is reduced
256 to a single element: scalar operations. This is in effect the default,
257 normal operating mode. However it is important to appreciate that this
258 does **not** result in the Register table or SUBVL being disabled. Only
259 when the Register table is empty (P48/64 prefix fields notwithstanding)
260 would SV have no effect.
262 ## SUBVL - Sub Vector Length
264 This is a "group by quantity" that effectivrly asks each iteration
265 of the hardware loop to load SUBVL elements of width elwidth at a
266 time. Effectively, SUBVL is like a SIMD multiplier: instead of just 1
267 operation issued, SUBVL operations are issued.
269 Another way to view SUBVL is that each element in the VL length vector is
270 now SUBVL times elwidth bits in length and now comprises SUBVL discrete
271 sub operations. An inner SUBVL for-loop within a VL for-loop in effect,
272 with the sub-element increased every time in the innermost loop. This
273 is best illustrated in the (simplified) pseudocode example, later.
275 The primary use case for SUBVL is for 3D FP Vectors. A Vector of 3D
276 coordinates X,Y,Z for example may be loaded and multiplied the stored, per
277 VL element iteration, rather than having to set VL to three times larger.
279 Legal values are 1, 2, 3 and 4 (and the STATE CSR must hold the 2 bit
280 values 0b00 thru 0b11 to represent them).
282 Setting this CSR to 0 must raise an exception. Setting it to a value
283 greater than 4 likewise.
285 The main effect of SUBVL is that predication bits are applied per
286 **group**, rather than by individual element.
288 This saves a not insignificant number of instructions when handling 3D
289 vectors, as otherwise a much longer predicate mask would have to be set
290 up with regularly-repeated bit patterns.
292 See SUBVL Pseudocode illustration for details.
296 This is a standard CSR that contains sufficient information for a
297 full context save/restore. It contains (and permits setting of):
301 * destoffs - the destination element offset of the current parallel
302 instruction being executed
303 * srcoffs - for twin-predication, the source element offset as well.
305 * svdestoffs - the subvector destination element offset of the current
306 parallel instruction being executed
307 * svsrcoffs - for twin-predication, the subvector source element offset
310 Interestingly STATE may hypothetically also be modified to make the
311 immediately-following instruction to skip a certain number of elements,
312 by playing with destoffs and srcoffs (and the subvector offsets as well)
314 Setting destoffs and srcoffs is realistically intended for saving state
315 so that exceptions (page faults in particular) may be serviced and the
316 hardware-loop that was being executed at the time of the trap, from
317 user-mode (or Supervisor-mode), may be returned to and continued from
318 exactly where it left off. The reason why this works is because setting
319 User-Mode STATE will not change (not be used) in M-Mode or S-Mode (and
320 is entirely why M-Mode and S-Mode have their own STATE CSRs, meSTATE
323 The format of the STATE CSR is as follows:
325 | (29..28 | (27..26) | (25..24) | (23..18) | (17..12) | (11..6) | (5...0) |
326 | ------- | -------- | -------- | -------- | -------- | ------- | ------- |
327 | dsvoffs | ssvoffs | subvl | destoffs | srcoffs | vl | maxvl |
329 When setting this CSR, the following characteristics will be enforced:
331 * **MAXVL** will be truncated (after offset) to be within the range 1 to XLEN
332 * **VL** will be truncated (after offset) to be within the range 1 to MAXVL
333 * **SUBVL** which sets a SIMD-like quantity, has only 4 values there
334 are no changes needed
335 * **srcoffs** will be truncated to be within the range 0 to VL-1
336 * **destoffs** will be truncated to be within the range 0 to VL-1
337 * **ssvoffs** will be truncated to be within the range 0 to SUBVL-1
338 * **dsvoffs** will be truncated to be within the range 0 to SUBVL-1
340 NOTE: if the following instruction is not a twin predicated instruction,
341 and destoffs or dsvoffs has been set to non-zero, subsequent execution
342 behaviour is undefined. **USE WITH CARE**.
344 ### Hardware rules for when to increment STATE offsets
346 The offsets inside STATE are like the indices in a loop, except
347 in hardware. They are also partially (conceptually) similar to a
348 "sub-execution Program Counter". As such, and to allow proper context
349 switching and to define correct exception behaviour, the following rules
352 * When the VL CSR is set, srcoffs and destoffs are reset to zero.
353 * Each instruction that contains a "tagged" register shall start
354 execution at the *current* value of srcoffs (and destoffs in the case
356 * Unpredicated bits (in nonzeroing mode) shall cause the element operation
357 to skip, incrementing the srcoffs (or destoffs)
358 * On execution of an element operation, Exceptions shall **NOT** cause
359 srcoffs or destoffs to increment.
360 * On completion of the full Vector Loop (srcoffs = VL-1 or destoffs =
361 VL-1 after the last element is executed), both srcoffs and destoffs
362 shall be reset to zero.
364 This latter is why srcoffs and destoffs may be stored as values from
365 0 to XLEN-1 in the STATE CSR, because as loop indices they refer to
366 elements. srcoffs and destoffs never need to be set to VL: their maximum
367 operating values are limited to 0 to VL-1.
369 The same corresponding rules apply to SUBVL, svsrcoffs and svdestoffs.
371 ## MVL and VL Pseudocode
373 The pseudo-code for get and set of VL and MVL use the following internal
374 functions as follows:
376 set_mvl_csr(value, rd):
378 STATE.MVL = MIN(value, STATE.MVL)
383 set_vl_csr(value, rd):
384 STATE.VL = MIN(value, STATE.MVL)
385 regs[rd] = STATE.VL # yes returning the new value NOT the old CSR
392 Note that where setting MVL behaves as a normal CSR (returns the old
393 value), unlike standard CSR behaviour, setting VL will return the **new**
394 value of VL **not** the old one.
396 For CSRRWI, the range of the immediate is restricted to 5 bits. In order to
397 maximise the effectiveness, an immediate of 0 is used to set VL=1,
398 an immediate of 1 is used to set VL=2 and so on:
400 CSRRWI_Set_MVL(value):
401 set_mvl_csr(value+1, x0)
403 CSRRWI_Set_VL(value):
404 set_vl_csr(value+1, x0)
406 However for CSRRW the following pseudocode is used for MVL and VL,
407 where setting the value to zero will cause an exception to be raised.
408 The reason is that if VL or MVL are set to zero, the STATE CSR is
409 not capable of storing that value.
411 CSRRW_Set_MVL(rs1, rd):
413 if value == 0 or value > XLEN:
415 set_mvl_csr(value, rd)
417 CSRRW_Set_VL(rs1, rd):
419 if value == 0 or value > XLEN:
421 set_vl_csr(value, rd)
423 In this way, when CSRRW is utilised with a loop variable, the value
424 that goes into VL (and into the destination register) may be used
425 in an instruction-minimal fashion:
427 CSRvect1 = {type: F, key: a3, val: a3, elwidth: dflt}
428 CSRvect2 = {type: F, key: a7, val: a7, elwidth: dflt}
429 CSRRWI MVL, 3 # sets MVL == **4** (not 3)
430 j zerotest # in case loop counter a0 already 0
432 CSRRW VL, t0, a0 # vl = t0 = min(mvl, a0)
433 ld a3, a1 # load 4 registers a3-6 from x
434 slli t1, t0, 3 # t1 = vl * 8 (in bytes)
435 ld a7, a2 # load 4 registers a7-10 from y
436 add a1, a1, t1 # increment pointer to x by vl*8
437 fmadd a7, a3, fa0, a7 # v1 += v0 * fa0 (y = a * x + y)
438 sub a0, a0, t0 # n -= vl (t0)
439 st a7, a2 # store 4 registers a7-10 to y
440 add a2, a2, t1 # increment pointer to y by vl*8
442 bnez a0, loop # repeat if n != 0
444 With the STATE CSR, just like with CSRRWI, in order to maximise the
445 utilisation of the limited bitspace, "000000" in binary represents
446 VL==1, "00001" represents VL==2 and so on (likewise for MVL):
448 CSRRW_Set_SV_STATE(rs1, rd):
451 STATE.MVL = set_mvl_csr(value[11:6]+1)
452 STATE.VL = set_vl_csr(value[5:0]+1)
453 STATE.destoffs = value[23:18]>>18
454 STATE.srcoffs = value[23:18]>>12
457 regs[rd] = (STATE.MVL-1) | (STATE.VL-1)<<6 | (STATE.srcoffs)<<12 |
461 In both cases, whilst CSR read of VL and MVL return the exact values
462 of VL and MVL respectively, reading and writing the STATE CSR returns
463 those values **minus one**. This is absolutely critical to implement
464 if the STATE CSR is to be used for fast context-switching.
466 ## VL, MVL and SUBVL instruction aliases
468 This table contains pseudo-assembly instruction aliases. Note the
469 subtraction of 1 from the CSRRWI pseudo variants, to compensate for the
470 reduced range of the 5 bit immediate.
474 | SETVL rd, rs | CSRRW VL, rd, rs |
475 | SETVLi rd, #n | CSRRWI VL, rd, #n-1 |
476 | GETVL rd | CSRRW VL, rd, x0 |
477 | SETMVL rd, rs | CSRRW MVL, rd, rs |
478 | SETMVLi rd, #n | CSRRWI MVL,rd, #n-1 |
479 | GETMVL rd | CSRRW MVL, rd, x0 |
481 Note: CSRRC and other bitsetting may still be used, they are however not particularly useful (very obscure).
483 ## Register key-value (CAM) table <a name="regcsrtable" />
485 *NOTE: in prior versions of SV, this table used to be writable and
486 accessible via CSRs. It is now stored in the VLIW instruction format. Note
487 that this table does *not* get applied to the SVPrefix P48/64 format,
488 only to scalar opcodes*
490 The purpose of the Register table is three-fold:
492 * To mark integer and floating-point registers as requiring "redirection"
493 if it is ever used as a source or destination in any given operation.
494 This involves a level of indirection through a 5-to-7-bit lookup table,
495 such that **unmodified** operands with 5 bits (3 for some RVC ops) may
496 access up to **128** registers.
497 * To indicate whether, after redirection through the lookup table, the
498 register is a vector (or remains a scalar).
499 * To over-ride the implicit or explicit bitwidth that the operation would
500 normally give the register.
502 Note: clearly, if an RVC operation uses a 3 bit spec'd register (x8-x15)
503 and the Register table contains entried that only refer to registerd
504 x1-x14 or x16-x31, such operations will *never* activate the VL hardware
507 If however the (16 bit) Register table does contain such an entry (x8-x15
508 or x2 in the case of LWSP), that src or dest reg may be redirected
509 anywhere to the *full* 128 register range. Thus, RVC becomes far more
510 powerful and has many more opportunities to reduce code size that in
511 Standard RV32/RV64 executables.
515 | RegCAM | | 15 | (14..8) | 7 | (6..5) | (4..0) |
516 | ------ | | - | - | - | ------ | ------- |
517 | 0 | | isvec0 | regidx0 | i/f | vew0 | regkey |
518 | 1 | | isvec1 | regidx1 | i/f | vew1 | regkey |
519 | .. | | isvec.. | regidx.. | i/f | vew.. | regkey |
520 | 15 | | isvec15 | regidx15 | i/f | vew15 | regkey |
524 | RegCAM | | 7 | (6..5) | (4..0) |
525 | ------ | | - | ------ | ------- |
526 | 0 | | i/f | vew0 | regnum |
528 i/f is set to "1" to indicate that the redirection/tag entry is to
529 be applied to integer registers; 0 indicates that it is relevant to
533 The 8 bit format is used for a much more compact expression. "isvec"
534 is implicit and, similar to [[sv-prefix-proposal]], the target vector
535 is "regnum<<2", implicitly. Contrast this with the 16-bit format where
536 the target vector is *explicitly* named in bits 8 to 14, and bit 15 may
537 optionally set "scalar" mode.
539 Note that whilst SVPrefix adds one extra bit to each of rd, rs1 etc.,
540 and thus the "vector" mode need only shift the (6 bit) regnum by 1 to
541 get the actual (7 bit) register number to use, there is not enough space
542 in the 8 bit format (only 5 bits for regnum) so "regnum<<2" is required.
544 vew has the following meanings, indicating that the instruction's
545 operand size is "over-ridden" in a polymorphic fashion:
548 | --- | ------------------- |
549 | 00 | default (XLEN/FLEN) |
554 As the above table is a CAM (key-value store) it may be appropriate
555 (faster, implementation-wise) to expand it as follows:
557 struct vectorised fp_vec[32], int_vec[32];
559 for (i = 0; i < len; i++) // from VLIW Format
560 tb = int_vec if CSRvec[i].type == 0 else fp_vec
561 idx = CSRvec[i].regkey // INT/FP src/dst reg in opcode
562 tb[idx].elwidth = CSRvec[i].elwidth
563 tb[idx].regidx = CSRvec[i].regidx // indirection
564 tb[idx].isvector = CSRvec[i].isvector // 0=scalar
566 ## Predication Table <a name="predication_csr_table"></a>
568 *NOTE: in prior versions of SV, this table used to be writable and
569 accessible via CSRs. It is now stored in the VLIW instruction format.
570 The table does **not** apply to SVPrefix opcodes*
572 The Predication Table is a key-value store indicating whether, if a
573 given destination register (integer or floating-point) is referred to
574 in an instruction, it is to be predicated. Like the Register table, it
575 is an indirect lookup that allows the RV opcodes to not need modification.
577 It is particularly important to note
578 that the *actual* register used can be *different* from the one that is
579 in the instruction, due to the redirection through the lookup table.
581 * regidx is the register that in combination with the
582 i/f flag, if that integer or floating-point register is referred to in a
583 (standard RV) instruction results in the lookup table being referenced
584 to find the predication mask to use for this operation.
585 * predidx is the *actual* (full, 7 bit) register to be used for the
587 * inv indicates that the predication mask bits are to be inverted
588 prior to use *without* actually modifying the contents of the
589 registerfrom which those bits originated.
590 * zeroing is either 1 or 0, and if set to 1, the operation must
591 place zeros in any element position where the predication mask is
592 set to zero. If zeroing is set to 0, unpredicated elements *must*
593 be left alone. Some microarchitectures may choose to interpret
594 this as skipping the operation entirely. Others which wish to
595 stick more closely to a SIMD architecture may choose instead to
596 interpret unpredicated elements as an internal "copy element"
597 operation (which would be necessary in SIMD microarchitectures
598 that perform register-renaming)
599 * ffirst is a special mode that stops sequential element processing when
600 a data-dependent condition occurs, whether a trap or a conditional test.
601 The handling of each (trap or conditional test) is slightly different:
602 see Instruction sections for further details
606 | PrCSR | (15..11) | 10 | 9 | 8 | (7..1) | 0 |
607 | ----- | - | - | - | - | ------- | ------- |
608 | 0 | predkey | zero0 | inv0 | i/f | regidx | ffirst0 |
609 | 1 | predkey | zero1 | inv1 | i/f | regidx | ffirst1 |
610 | 2 | predkey | zero2 | inv2 | i/f | regidx | ffirst2 |
611 | 3 | predkey | zero3 | inv3 | i/f | regidx | ffirst3 |
615 | PrCSR | 7 | 6 | 5 | (4..0) |
616 | ----- | - | - | - | ------- |
617 | 0 | zero0 | inv0 | i/f | regnum |
619 The 8 bit format is a compact and less expressive variant of the full
620 16 bit format. Using the 8 bit formatis very different: the predicate
621 register to use is implicit, and numbering begins inplicitly from x9. The
622 regnum is still used to "activate" predication, in the same fashion as
625 The 16 bit Predication CSR Table is a key-value store, so
626 implementation-wise it will be faster to turn the table around (maintain
627 topologically equivalent state):
634 int predidx; // redirection: actual int register to use
637 struct pred fp_pred_reg[32]; // 64 in future (bank=1)
638 struct pred int_pred_reg[32]; // 64 in future (bank=1)
640 for (i = 0; i < 16; i++)
641 tb = int_pred_reg if CSRpred[i].type == 0 else fp_pred_reg;
642 idx = CSRpred[i].regidx
643 tb[idx].zero = CSRpred[i].zero
644 tb[idx].inv = CSRpred[i].inv
645 tb[idx].ffirst = CSRpred[i].ffirst
646 tb[idx].predidx = CSRpred[i].predidx
647 tb[idx].enabled = true
649 So when an operation is to be predicated, it is the internal state that
650 is used. In Section 6.4.2 of Hwacha's Manual (EECS-2015-262) the following
651 pseudo-code for operations is given, where p is the explicit (direct)
652 reference to the predication register to be used:
654 for (int i=0; i<vl; ++i)
656 (d ? vreg[rd][i] : sreg[rd]) =
657 iop(s1 ? vreg[rs1][i] : sreg[rs1],
658 s2 ? vreg[rs2][i] : sreg[rs2]); // for insts with 2 inputs
660 This instead becomes an *indirect* reference using the *internal* state
661 table generated from the Predication CSR key-value store, which is used
665 preg = int_pred_reg[rd]
667 preg = fp_pred_reg[rd]
669 for (int i=0; i<vl; ++i)
670 predicate, zeroing = get_pred_val(type(iop) == INT, rd):
671 if (predicate && (1<<i))
672 (d ? regfile[rd+i] : regfile[rd]) =
673 iop(s1 ? regfile[rs1+i] : regfile[rs1],
674 s2 ? regfile[rs2+i] : regfile[rs2]); // for insts with 2 inputs
676 (d ? regfile[rd+i] : regfile[rd]) = 0
680 * d, s1 and s2 are booleans indicating whether destination,
681 source1 and source2 are vector or scalar
682 * key-value CSR-redirection of rd, rs1 and rs2 have NOT been included
683 above, for clarity. rd, rs1 and rs2 all also must ALSO go through
684 register-level redirection (from the Register table) if they are
687 If written as a function, obtaining the predication mask (and whether
688 zeroing takes place) may be done as follows:
690 def get_pred_val(bool is_fp_op, int reg):
691 tb = int_reg if is_fp_op else fp_reg
692 if (!tb[reg].enabled):
693 return ~0x0, False // all enabled; no zeroing
694 tb = int_pred if is_fp_op else fp_pred
695 if (!tb[reg].enabled):
696 return ~0x0, False // all enabled; no zeroing
697 predidx = tb[reg].predidx // redirection occurs HERE
698 predicate = intreg[predidx] // actual predicate HERE
700 predicate = ~predicate // invert ALL bits
701 return predicate, tb[reg].zero
703 Note here, critically, that **only** if the register is marked
704 in its **register** table entry as being "active" does the testing
705 proceed further to check if the **predicate** table entry is
708 Note also that this is in direct contrast to branch operations
709 for the storage of comparisions: in these specific circumstances
710 the requirement for there to be an active *register* entry
713 ## Fail-on-First Mode
715 * ffirst is a special mode that, except for the first element,
716 stops sequential element processing when a trap or fail-condition
718 The first element is treated normally (as if ffirst is clear).
719 Should any subsequent element instruction require a trap, instead
720 it and subsequent indexed elements are ignored (or cancelled in
721 out-of-order designs), and VL is set to the *last* instruction
722 that did not take the trap.
724 ## REMAP CSR <a name="remap" />
726 (Note: both the REMAP and SHAPE sections are best read after the
727 rest of the document has been read)
729 There is one 32-bit CSR which may be used to indicate which registers,
730 if used in any operation, must be "reshaped" (re-mapped) from a linear
731 form to a 2D or 3D transposed form, or "offset" to permit arbitrary
732 access to elements within a register.
734 The 32-bit REMAP CSR may reshape up to 3 registers:
736 | 29..28 | 27..26 | 25..24 | 23 | 22..16 | 15 | 14..8 | 7 | 6..0 |
737 | ------ | ------ | ------ | -- | ------- | -- | ------- | -- | ------- |
738 | shape2 | shape1 | shape0 | 0 | regidx2 | 0 | regidx1 | 0 | regidx0 |
740 regidx0-2 refer not to the Register CSR CAM entry but to the underlying
741 *real* register (see regidx, the value) and consequently is 7-bits wide.
742 When set to zero (referring to x0), clearly reshaping x0 is pointless,
743 so is used to indicate "disabled".
744 shape0-2 refers to one of three SHAPE CSRs. A value of 0x3 is reserved.
745 Bits 7, 15, 23, 30 and 31 are also reserved, and must be set to zero.
747 It is anticipated that these specialist CSRs not be very often used.
748 Unlike the CSR Register and Predication tables, the REMAP CSRs use
749 the full 7-bit regidx so that they can be set once and left alone,
750 whilst the CSR Register entries pointing to them are disabled, instead.
752 ## SHAPE 1D/2D/3D vector-matrix remapping CSRs
754 (Note: both the REMAP and SHAPE sections are best read after the
755 rest of the document has been read)
757 There are three "shape" CSRs, SHAPE0, SHAPE1, SHAPE2, 32-bits in each,
758 which have the same format. When each SHAPE CSR is set entirely to zeros,
759 remapping is disabled: the register's elements are a linear (1D) vector.
761 | 26..24 | 23 | 22..16 | 15 | 14..8 | 7 | 6..0 |
762 | ------- | -- | ------- | -- | ------- | -- | ------- |
763 | permute | offs[2] | zdimsz | offs[1] | ydimsz | offs[0] | xdimsz |
765 offs is a 3-bit field, spread out across bits 7, 15 and 23, which
766 is added to the element index during the loop calculation.
768 xdimsz, ydimsz and zdimsz are offset by 1, such that a value of 0 indicates
769 that the array dimensionality for that dimension is 1. A value of xdimsz=2
770 would indicate that in the first dimension there are 3 elements in the
771 array. The format of the array is therefore as follows:
773 array[xdim+1][ydim+1][zdim+1]
775 However whilst illustrative of the dimensionality, that does not take the
776 "permute" setting into account. "permute" may be any one of six values
777 (0-5, with values of 6 and 7 being reserved, and not legal). The table
778 below shows how the permutation dimensionality order works:
780 | permute | order | array format |
781 | ------- | ----- | ------------------------ |
782 | 000 | 0,1,2 | (xdim+1)(ydim+1)(zdim+1) |
783 | 001 | 0,2,1 | (xdim+1)(zdim+1)(ydim+1) |
784 | 010 | 1,0,2 | (ydim+1)(xdim+1)(zdim+1) |
785 | 011 | 1,2,0 | (ydim+1)(zdim+1)(xdim+1) |
786 | 100 | 2,0,1 | (zdim+1)(xdim+1)(ydim+1) |
787 | 101 | 2,1,0 | (zdim+1)(ydim+1)(xdim+1) |
789 In other words, the "permute" option changes the order in which
790 nested for-loops over the array would be done. The algorithm below
791 shows this more clearly, and may be executed as a python program:
793 # mapidx = REMAP.shape2
794 xdim = 3 # SHAPE[mapidx].xdim_sz+1
795 ydim = 4 # SHAPE[mapidx].ydim_sz+1
796 zdim = 5 # SHAPE[mapidx].zdim_sz+1
798 lims = [xdim, ydim, zdim]
799 idxs = [0,0,0] # starting indices
800 order = [1,0,2] # experiment with different permutations, here
801 offs = 0 # experiment with different offsets, here
803 for idx in range(xdim * ydim * zdim):
804 new_idx = offs + idxs[0] + idxs[1] * xdim + idxs[2] * xdim * ydim
807 idxs[order[i]] = idxs[order[i]] + 1
808 if (idxs[order[i]] != lims[order[i]]):
813 Here, it is assumed that this algorithm be run within all pseudo-code
814 throughout this document where a (parallelism) for-loop would normally
815 run from 0 to VL-1 to refer to contiguous register
816 elements; instead, where REMAP indicates to do so, the element index
817 is run through the above algorithm to work out the **actual** element
818 index, instead. Given that there are three possible SHAPE entries, up to
819 three separate registers in any given operation may be simultaneously
822 function op_add(rd, rs1, rs2) # add not VADD!
825 for (i = 0; i < VL; i++)
826 xSTATE.srcoffs = i # save context
827 if (predval & 1<<i) # predication uses intregs
828 ireg[rd+remap(id)] <= ireg[rs1+remap(irs1)] +
829 ireg[rs2+remap(irs2)];
830 if (!int_vec[rd ].isvector) break;
831 if (int_vec[rd ].isvector) { id += 1; }
832 if (int_vec[rs1].isvector) { irs1 += 1; }
833 if (int_vec[rs2].isvector) { irs2 += 1; }
835 By changing remappings, 2D matrices may be transposed "in-place" for one
836 operation, followed by setting a different permutation order without
837 having to move the values in the registers to or from memory. Also,
838 the reason for having REMAP separate from the three SHAPE CSRs is so
839 that in a chain of matrix multiplications and additions, for example,
840 the SHAPE CSRs need only be set up once; only the REMAP CSR need be
841 changed to target different registers.
845 * Over-running the register file clearly has to be detected and
846 an illegal instruction exception thrown
847 * When non-default elwidths are set, the exact same algorithm still
848 applies (i.e. it offsets elements *within* registers rather than
850 * If permute option 000 is utilised, the actual order of the
851 reindexing does not change!
852 * If two or more dimensions are set to zero, the actual order does not change!
853 * The above algorithm is pseudo-code **only**. Actual implementations
854 will need to take into account the fact that the element for-looping
855 must be **re-entrant**, due to the possibility of exceptions occurring.
856 See MSTATE CSR, which records the current element index.
857 * Twin-predicated operations require **two** separate and distinct
858 element offsets. The above pseudo-code algorithm will be applied
859 separately and independently to each, should each of the two
860 operands be remapped. *This even includes C.LDSP* and other operations
861 in that category, where in that case it will be the **offset** that is
862 remapped (see Compressed Stack LOAD/STORE section).
863 * Offset is especially useful, on its own, for accessing elements
864 within the middle of a register. Without offsets, it is necessary
865 to either use a predicated MV, skipping the first elements, or
866 performing a LOAD/STORE cycle to memory.
867 With offsets, the data does not have to be moved.
868 * Setting the total elements (xdim+1) times (ydim+1) times (zdim+1) to
869 less than MVL is **perfectly legal**, albeit very obscure. It permits
870 entries to be regularly presented to operands **more than once**, thus
871 allowing the same underlying registers to act as an accumulator of
872 multiple vector or matrix operations, for example.
874 Clearly here some considerable care needs to be taken as the remapping
875 could hypothetically create arithmetic operations that target the
876 exact same underlying registers, resulting in data corruption due to
877 pipeline overlaps. Out-of-order / Superscalar micro-architectures with
878 register-renaming will have an easier time dealing with this than
879 DSP-style SIMD micro-architectures.
881 # Instruction Execution Order
883 Simple-V behaves as if it is a hardware-level "macro expansion system",
884 substituting and expanding a single instruction into multiple sequential
885 instructions with contiguous and sequentially-incrementing registers.
886 As such, it does **not** modify - or specify - the behaviour and semantics of
887 the execution order: that may be deduced from the **existing** RV
888 specification in each and every case.
890 So for example if a particular micro-architecture permits out-of-order
891 execution, and it is augmented with Simple-V, then wherever instructions
892 may be out-of-order then so may the "post-expansion" SV ones.
894 If on the other hand there are memory guarantees which specifically
895 prevent and prohibit certain instructions from being re-ordered
896 (such as the Atomicity Axiom, or FENCE constraints), then clearly
897 those constraints **MUST** also be obeyed "post-expansion".
899 It should be absolutely clear that SV is **not** about providing new
900 functionality or changing the existing behaviour of a micro-architetural
901 design, or about changing the RISC-V Specification.
902 It is **purely** about compacting what would otherwise be contiguous
903 instructions that use sequentially-increasing register numbers down
904 to the **one** instruction.
906 # Instructions <a name="instructions" />
908 Despite being a 98% complete and accurate topological remap of RVV
909 concepts and functionality, no new instructions are needed.
910 Compared to RVV: *All* RVV instructions can be re-mapped, however xBitManip
911 becomes a critical dependency for efficient manipulation of predication
912 masks (as a bit-field). Despite the removal of all operations,
913 with the exception of CLIP and VSELECT.X
914 *all instructions from RVV Base are topologically re-mapped and retain their
915 complete functionality, intact*. Note that if RV64G ever had
916 a MV.X added as well as FCLIP, the full functionality of RVV-Base would
919 Three instructions, VSELECT, VCLIP and VCLIPI, do not have RV Standard
920 equivalents, so are left out of Simple-V. VSELECT could be included if
921 there existed a MV.X instruction in RV (MV.X is a hypothetical
922 non-immediate variant of MV that would allow another register to
923 specify which register was to be copied). Note that if any of these three
924 instructions are added to any given RV extension, their functionality
925 will be inherently parallelised.
927 With some exceptions, where it does not make sense or is simply too
928 challenging, all RV-Base instructions are parallelised:
930 * CSR instructions, whilst a case could be made for fast-polling of
931 a CSR into multiple registers, or for being able to copy multiple
932 contiguously addressed CSRs into contiguous registers, and so on,
933 are the fundamental core basis of SV. If parallelised, extreme
934 care would need to be taken. Additionally, CSR reads are done
935 using x0, and it is *really* inadviseable to tag x0.
936 * LUI, C.J, C.JR, WFI, AUIPC are not suitable for parallelising so are
938 * LR/SC could hypothetically be parallelised however their purpose is
939 single (complex) atomic memory operations where the LR must be followed
940 up by a matching SC. A sequence of parallel LR instructions followed
941 by a sequence of parallel SC instructions therefore is guaranteed to
942 not be useful. Not least: the guarantees of a Multi-LR/SC
943 would be impossible to provide if emulated in a trap.
944 * EBREAK, NOP, FENCE and others do not use registers so are not inherently
945 paralleliseable anyway.
947 All other operations using registers are automatically parallelised.
948 This includes AMOMAX, AMOSWAP and so on, where particular care and
949 attention must be paid.
951 Example pseudo-code for an integer ADD operation (including scalar operations).
952 Floating-point uses fp csrs.
954 function op_add(rd, rs1, rs2) # add not VADD!
955 int i, id=0, irs1=0, irs2=0;
956 predval = get_pred_val(FALSE, rd);
957 rd = int_vec[rd ].isvector ? int_vec[rd ].regidx : rd;
958 rs1 = int_vec[rs1].isvector ? int_vec[rs1].regidx : rs1;
959 rs2 = int_vec[rs2].isvector ? int_vec[rs2].regidx : rs2;
960 for (i = 0; i < VL; i++)
961 xSTATE.srcoffs = i # save context
962 if (predval & 1<<i) # predication uses intregs
963 ireg[rd+id] <= ireg[rs1+irs1] + ireg[rs2+irs2];
964 if (!int_vec[rd ].isvector) break;
965 if (int_vec[rd ].isvector) { id += 1; }
966 if (int_vec[rs1].isvector) { irs1 += 1; }
967 if (int_vec[rs2].isvector) { irs2 += 1; }
969 Note that for simplicity there is quite a lot missing from the above
970 pseudo-code: element widths, zeroing on predication, dimensional
971 reshaping and offsets and so on. However it demonstrates the basic
972 principle. Augmentations that produce the full pseudo-code are covered in
977 Adding in support for SUBVL is a matter of adding in an extra inner for-loop, where register src and dest are still incremented inside the inner part. Not that the predication is still taken from the VL index.
979 So whilst elements are indexed by (i * SUBVL + s), predicate bits are indexed by i
981 function op_add(rd, rs1, rs2) # add not VADD!
982 int i, id=0, irs1=0, irs2=0;
983 predval = get_pred_val(FALSE, rd);
984 rd = int_vec[rd ].isvector ? int_vec[rd ].regidx : rd;
985 rs1 = int_vec[rs1].isvector ? int_vec[rs1].regidx : rs1;
986 rs2 = int_vec[rs2].isvector ? int_vec[rs2].regidx : rs2;
987 for (i = 0; i < VL; i++)
988 xSTATE.srcoffs = i # save context
989 for (s = 0; s < SUBVL; s++)
990 xSTATE.ssvoffs = s # save context
991 if (predval & 1<<i) # predication uses intregs
992 # actual add is here (at last)
993 ireg[rd+id] <= ireg[rs1+irs1] + ireg[rs2+irs2];
994 if (!int_vec[rd ].isvector) break;
995 if (int_vec[rd ].isvector) { id += 1; }
996 if (int_vec[rs1].isvector) { irs1 += 1; }
997 if (int_vec[rs2].isvector) { irs2 += 1; }
998 if (id == VL or irs1 == VL or irs2 == VL) {
999 # end VL hardware loop
1000 xSTATE.srcoffs = 0; # reset
1001 xSTATE.ssvoffs = 0; # reset
1006 NOTE: pseudocode simplified greatly: zeroing, proper predicate handling, elwidth handling etc. all left out.
1008 ## Instruction Format
1010 It is critical to appreciate that there are
1011 **no operations added to SV, at all**.
1013 Instead, by using CSRs to tag registers as an indication of "changed
1014 behaviour", SV *overloads* pre-existing branch operations into predicated
1015 variants, and implicitly overloads arithmetic operations, MV, FCVT, and
1016 LOAD/STORE depending on CSR configurations for bitwidth and predication.
1017 **Everything** becomes parallelised. *This includes Compressed
1018 instructions* as well as any future instructions and Custom Extensions.
1020 Note: CSR tags to change behaviour of instructions is nothing new, including
1021 in RISC-V. UXL, SXL and MXL change the behaviour so that XLEN=32/64/128.
1022 FRM changes the behaviour of the floating-point unit, to alter the rounding
1023 mode. Other architectures change the LOAD/STORE byte-order from big-endian
1024 to little-endian on a per-instruction basis. SV is just a little more...
1025 comprehensive in its effect on instructions.
1027 ## Branch Instructions
1029 ### Standard Branch <a name="standard_branch"></a>
1031 Branch operations use standard RV opcodes that are reinterpreted to
1032 be "predicate variants" in the instance where either of the two src
1033 registers are marked as vectors (active=1, vector=1).
1035 Note that the predication register to use (if one is enabled) is taken from
1036 the *first* src register, and that this is used, just as with predicated
1037 arithmetic operations, to mask whether the comparison operations take
1038 place or not. The target (destination) predication register
1039 to use (if one is enabled) is taken from the *second* src register.
1041 If either of src1 or src2 are scalars (whether by there being no
1042 CSR register entry or whether by the CSR entry specifically marking
1043 the register as "scalar") the comparison goes ahead as vector-scalar
1046 In instances where no vectorisation is detected on either src registers
1047 the operation is treated as an absolutely standard scalar branch operation.
1048 Where vectorisation is present on either or both src registers, the
1049 branch may stil go ahead if any only if *all* tests succeed (i.e. excluding
1050 those tests that are predicated out).
1052 Note that when zero-predication is enabled (from source rs1),
1053 a cleared bit in the predicate indicates that the result
1054 of the compare is set to "false", i.e. that the corresponding
1055 destination bit (or result)) be set to zero. Contrast this with
1056 when zeroing is not set: bits in the destination predicate are
1057 only *set*; they are **not** cleared. This is important to appreciate,
1058 as there may be an expectation that, going into the hardware-loop,
1059 the destination predicate is always expected to be set to zero:
1060 this is **not** the case. The destination predicate is only set
1061 to zero if **zeroing** is enabled.
1063 Note that just as with the standard (scalar, non-predicated) branch
1064 operations, BLE, BGT, BLEU and BTGU may be synthesised by inverting
1067 In Hwacha EECS-2015-262 Section 6.7.2 the following pseudocode is given
1068 for predicated compare operations of function "cmp":
1070 for (int i=0; i<vl; ++i)
1072 preg[pd][i] = cmp(s1 ? vreg[rs1][i] : sreg[rs1],
1073 s2 ? vreg[rs2][i] : sreg[rs2]);
1075 With associated predication, vector-length adjustments and so on,
1076 and temporarily ignoring bitwidth (which makes the comparisons more
1077 complex), this becomes:
1079 s1 = reg_is_vectorised(src1);
1080 s2 = reg_is_vectorised(src2);
1083 if cmp(rs1, rs2) # scalar compare
1087 preg = int_pred_reg[rd]
1090 ps = get_pred_val(I/F==INT, rs1);
1091 rd = get_pred_val(I/F==INT, rs2); # this may not exist
1093 if not exists(rd) or zeroing:
1098 for (int i = 0; i < VL; ++i)
1100 if not (ps & (1<<i))
1102 else if (ps & (1<<i))
1103 if (cmp(s1 ? reg[src1+i]:reg[src1],
1104 s2 ? reg[src2+i]:reg[src2])
1113 preg[rd] = result # store in destination
1119 * Predicated SIMD comparisons would break src1 and src2 further down
1120 into bitwidth-sized chunks (see Appendix "Bitwidth Virtual Register
1121 Reordering") setting Vector-Length times (number of SIMD elements) bits
1122 in Predicate Register rd, as opposed to just Vector-Length bits.
1123 * The execution of "parallelised" instructions **must** be implemented
1124 as "re-entrant" (to use a term from software). If an exception (trap)
1125 occurs during the middle of a vectorised
1126 Branch (now a SV predicated compare) operation, the partial results
1127 of any comparisons must be written out to the destination
1128 register before the trap is permitted to begin. If however there
1129 is no predicate, the **entire** set of comparisons must be **restarted**,
1130 with the offset loop indices set back to zero. This is because
1131 there is no place to store the temporary result during the handling
1134 TODO: predication now taken from src2. also branch goes ahead
1135 if all compares are successful.
1137 Note also that where normally, predication requires that there must
1138 also be a CSR register entry for the register being used in order
1139 for the **predication** CSR register entry to also be active,
1140 for branches this is **not** the case. src2 does **not** have
1141 to have its CSR register entry marked as active in order for
1142 predication on src2 to be active.
1144 Also note: SV Branch operations are **not** twin-predicated
1145 (see Twin Predication section). This would require three
1146 element offsets: one to track src1, one to track src2 and a third
1147 to track where to store the accumulation of the results. Given
1148 that the element offsets need to be exposed via CSRs so that
1149 the parallel hardware looping may be made re-entrant on traps
1150 and exceptions, the decision was made not to make SV Branches
1153 ### Floating-point Comparisons
1155 There does not exist floating-point branch operations, only compare.
1156 Interestingly no change is needed to the instruction format because
1157 FP Compare already stores a 1 or a zero in its "rd" integer register
1158 target, i.e. it's not actually a Branch at all: it's a compare.
1160 In RV (scalar) Base, a branch on a floating-point compare is
1161 done via the sequence "FEQ x1, f0, f5; BEQ x1, x0, #jumploc".
1162 This does extend to SV, as long as x1 (in the example sequence given)
1163 is vectorised. When that is the case, x1..x(1+VL-1) will also be
1164 set to 0 or 1 depending on whether f0==f5, f1==f6, f2==f7 and so on.
1165 The BEQ that follows will *also* compare x1==x0, x2==x0, x3==x0 and
1166 so on. Consequently, unlike integer-branch, FP Compare needs no
1167 modification in its behaviour.
1169 In addition, it is noted that an entry "FNE" (the opposite of FEQ) is missing,
1170 and whilst in ordinary branch code this is fine because the standard
1171 RVF compare can always be followed up with an integer BEQ or a BNE (or
1172 a compressed comparison to zero or non-zero), in predication terms that
1173 becomes more of an impact. To deal with this, SV's predication has
1174 had "invert" added to it.
1176 Also: note that FP Compare may be predicated, using the destination
1177 integer register (rd) to determine the predicate. FP Compare is **not**
1178 a twin-predication operation, as, again, just as with SV Branches,
1179 there are three registers involved: FP src1, FP src2 and INT rd.
1181 ### Compressed Branch Instruction
1183 Compressed Branch instructions are, just like standard Branch instructions,
1184 reinterpreted to be vectorised and predicated based on the source register
1185 (rs1s) CSR entries. As however there is only the one source register,
1186 given that c.beqz a10 is equivalent to beqz a10,x0, the optional target
1187 to store the results of the comparisions is taken from CSR predication
1188 table entries for **x0**.
1190 The specific required use of x0 is, with a little thought, quite obvious,
1191 but is counterintuitive. Clearly it is **not** recommended to redirect
1192 x0 with a CSR register entry, however as a means to opaquely obtain
1193 a predication target it is the only sensible option that does not involve
1194 additional special CSRs (or, worse, additional special opcodes).
1196 Note also that, just as with standard branches, the 2nd source
1197 (in this case x0 rather than src2) does **not** have to have its CSR
1198 register table marked as "active" in order for predication to work.
1200 ## Vectorised Dual-operand instructions
1202 There is a series of 2-operand instructions involving copying (and
1203 sometimes alteration):
1206 * FMV, FNEG, FABS, FCVT, FSGNJ, FSGNJN and FSGNJX
1207 * C.LWSP, C.SWSP, C.LDSP, C.FLWSP etc.
1208 * LOAD(-FP) and STORE(-FP)
1210 All of these operations follow the same two-operand pattern, so it is
1211 *both* the source *and* destination predication masks that are taken into
1212 account. This is different from
1213 the three-operand arithmetic instructions, where the predication mask
1214 is taken from the *destination* register, and applied uniformly to the
1215 elements of the source register(s), element-for-element.
1217 The pseudo-code pattern for twin-predicated operations is as
1220 function op(rd, rs):
1221 rd = int_csr[rd].active ? int_csr[rd].regidx : rd;
1222 rs = int_csr[rs].active ? int_csr[rs].regidx : rs;
1223 ps = get_pred_val(FALSE, rs); # predication on src
1224 pd = get_pred_val(FALSE, rd); # ... AND on dest
1225 for (int i = 0, int j = 0; i < VL && j < VL;):
1226 if (int_csr[rs].isvec) while (!(ps & 1<<i)) i++;
1227 if (int_csr[rd].isvec) while (!(pd & 1<<j)) j++;
1228 xSTATE.srcoffs = i # save context
1229 xSTATE.destoffs = j # save context
1230 reg[rd+j] = SCALAR_OPERATION_ON(reg[rs+i])
1231 if (int_csr[rs].isvec) i++;
1232 if (int_csr[rd].isvec) j++; else break
1234 This pattern covers scalar-scalar, scalar-vector, vector-scalar
1235 and vector-vector, and predicated variants of all of those.
1236 Zeroing is not presently included (TODO). As such, when compared
1237 to RVV, the twin-predicated variants of C.MV and FMV cover
1238 **all** standard vector operations: VINSERT, VSPLAT, VREDUCE,
1239 VEXTRACT, VSCATTER, VGATHER, VCOPY, and more.
1243 * elwidth (SIMD) is not covered in the pseudo-code above
1244 * ending the loop early in scalar cases (VINSERT, VEXTRACT) is also
1246 * zero predication is also not shown (TODO).
1248 ### C.MV Instruction <a name="c_mv"></a>
1250 There is no MV instruction in RV however there is a C.MV instruction.
1251 It is used for copying integer-to-integer registers (vectorised FMV
1252 is used for copying floating-point).
1254 If either the source or the destination register are marked as vectors
1255 C.MV is reinterpreted to be a vectorised (multi-register) predicated
1256 move operation. The actual instruction's format does not change:
1259 15 12 | 11 7 | 6 2 | 1 0 |
1260 funct4 | rd | rs | op |
1262 C.MV | dest | src | C0 |
1265 A simplified version of the pseudocode for this operation is as follows:
1267 function op_mv(rd, rs) # MV not VMV!
1268 rd = int_csr[rd].active ? int_csr[rd].regidx : rd;
1269 rs = int_csr[rs].active ? int_csr[rs].regidx : rs;
1270 ps = get_pred_val(FALSE, rs); # predication on src
1271 pd = get_pred_val(FALSE, rd); # ... AND on dest
1272 for (int i = 0, int j = 0; i < VL && j < VL;):
1273 if (int_csr[rs].isvec) while (!(ps & 1<<i)) i++;
1274 if (int_csr[rd].isvec) while (!(pd & 1<<j)) j++;
1275 xSTATE.srcoffs = i # save context
1276 xSTATE.destoffs = j # save context
1277 ireg[rd+j] <= ireg[rs+i];
1278 if (int_csr[rs].isvec) i++;
1279 if (int_csr[rd].isvec) j++; else break
1281 There are several different instructions from RVV that are covered by
1285 src | dest | predication | op |
1286 scalar | vector | none | VSPLAT |
1287 scalar | vector | destination | sparse VSPLAT |
1288 scalar | vector | 1-bit dest | VINSERT |
1289 vector | scalar | 1-bit? src | VEXTRACT |
1290 vector | vector | none | VCOPY |
1291 vector | vector | src | Vector Gather |
1292 vector | vector | dest | Vector Scatter |
1293 vector | vector | src & dest | Gather/Scatter |
1294 vector | vector | src == dest | sparse VCOPY |
1297 Also, VMERGE may be implemented as back-to-back (macro-op fused) C.MV
1298 operations with inversion on the src and dest predication for one of the
1299 two C.MV operations.
1301 Note that in the instance where the Compressed Extension is not implemented,
1302 MV may be used, but that is a pseudo-operation mapping to addi rd, x0, rs.
1303 Note that the behaviour is **different** from C.MV because with addi the
1304 predication mask to use is taken **only** from rd and is applied against
1305 all elements: rs[i] = rd[i].
1307 ### FMV, FNEG and FABS Instructions
1309 These are identical in form to C.MV, except covering floating-point
1310 register copying. The same double-predication rules also apply.
1311 However when elwidth is not set to default the instruction is implicitly
1312 and automatic converted to a (vectorised) floating-point type conversion
1313 operation of the appropriate size covering the source and destination
1316 (Note that FMV, FNEG and FABS are all actually pseudo-instructions)
1318 ### FVCT Instructions
1320 These are again identical in form to C.MV, except that they cover
1321 floating-point to integer and integer to floating-point. When element
1322 width in each vector is set to default, the instructions behave exactly
1323 as they are defined for standard RV (scalar) operations, except vectorised
1324 in exactly the same fashion as outlined in C.MV.
1326 However when the source or destination element width is not set to default,
1327 the opcode's explicit element widths are *over-ridden* to new definitions,
1328 and the opcode's element width is taken as indicative of the SIMD width
1329 (if applicable i.e. if packed SIMD is requested) instead.
1331 For example FCVT.S.L would normally be used to convert a 64-bit
1332 integer in register rs1 to a 64-bit floating-point number in rd.
1333 If however the source rs1 is set to be a vector, where elwidth is set to
1334 default/2 and "packed SIMD" is enabled, then the first 32 bits of
1335 rs1 are converted to a floating-point number to be stored in rd's
1336 first element and the higher 32-bits *also* converted to floating-point
1337 and stored in the second. The 32 bit size comes from the fact that
1338 FCVT.S.L's integer width is 64 bit, and with elwidth on rs1 set to
1339 divide that by two it means that rs1 element width is to be taken as 32.
1341 Similar rules apply to the destination register.
1343 ## LOAD / STORE Instructions and LOAD-FP/STORE-FP <a name="load_store"></a>
1345 An earlier draft of SV modified the behaviour of LOAD/STORE (modified
1346 the interpretation of the instruction fields). This
1347 actually undermined the fundamental principle of SV, namely that there
1348 be no modifications to the scalar behaviour (except where absolutely
1349 necessary), in order to simplify an implementor's task if considering
1350 converting a pre-existing scalar design to support parallelism.
1352 So the original RISC-V scalar LOAD/STORE and LOAD-FP/STORE-FP functionality
1353 do not change in SV, however just as with C.MV it is important to note
1354 that dual-predication is possible.
1356 In vectorised architectures there are usually at least two different modes
1359 * Read (or write for STORE) from sequential locations, where one
1360 register specifies the address, and the one address is incremented
1361 by a fixed amount. This is usually known as "Unit Stride" mode.
1362 * Read (or write) from multiple indirected addresses, where the
1363 vector elements each specify separate and distinct addresses.
1365 To support these different addressing modes, the CSR Register "isvector"
1366 bit is used. So, for a LOAD, when the src register is set to
1367 scalar, the LOADs are sequentially incremented by the src register
1368 element width, and when the src register is set to "vector", the
1369 elements are treated as indirection addresses. Simplified
1370 pseudo-code would look like this:
1372 function op_ld(rd, rs) # LD not VLD!
1373 rdv = int_csr[rd].active ? int_csr[rd].regidx : rd;
1374 rsv = int_csr[rs].active ? int_csr[rs].regidx : rs;
1375 ps = get_pred_val(FALSE, rs); # predication on src
1376 pd = get_pred_val(FALSE, rd); # ... AND on dest
1377 for (int i = 0, int j = 0; i < VL && j < VL;):
1378 if (int_csr[rs].isvec) while (!(ps & 1<<i)) i++;
1379 if (int_csr[rd].isvec) while (!(pd & 1<<j)) j++;
1380 if (int_csr[rd].isvec)
1381 # indirect mode (multi mode)
1382 srcbase = ireg[rsv+i];
1385 srcbase = ireg[rsv] + i * XLEN/8; # offset in bytes
1386 ireg[rdv+j] <= mem[srcbase + imm_offs];
1387 if (!int_csr[rs].isvec &&
1388 !int_csr[rd].isvec) break # scalar-scalar LD
1389 if (int_csr[rs].isvec) i++;
1390 if (int_csr[rd].isvec) j++;
1394 * For simplicity, zeroing and elwidth is not included in the above:
1395 the key focus here is the decision-making for srcbase; vectorised
1396 rs means use sequentially-numbered registers as the indirection
1397 address, and scalar rs is "offset" mode.
1398 * The test towards the end for whether both source and destination are
1399 scalar is what makes the above pseudo-code provide the "standard" RV
1400 Base behaviour for LD operations.
1401 * The offset in bytes (XLEN/8) changes depending on whether the
1402 operation is a LB (1 byte), LH (2 byes), LW (4 bytes) or LD
1403 (8 bytes), and also whether the element width is over-ridden
1404 (see special element width section).
1406 ## Compressed Stack LOAD / STORE Instructions <a name="c_ld_st"></a>
1408 C.LWSP / C.SWSP and floating-point etc. are also source-dest twin-predicated,
1409 where it is implicit in C.LWSP/FLWSP etc. that x2 is the source register.
1410 It is therefore possible to use predicated C.LWSP to efficiently
1411 pop registers off the stack (by predicating x2 as the source), cherry-picking
1412 which registers to store to (by predicating the destination). Likewise
1413 for C.SWSP. In this way, LOAD/STORE-Multiple is efficiently achieved.
1415 The two modes ("unit stride" and multi-indirection) are still supported,
1416 as with standard LD/ST. Essentially, the only difference is that the
1417 use of x2 is hard-coded into the instruction.
1419 **Note**: it is still possible to redirect x2 to an alternative target
1420 register. With care, this allows C.LWSP / C.SWSP (and C.FLWSP) to be used as
1421 general-purpose LOAD/STORE operations.
1423 ## Compressed LOAD / STORE Instructions
1425 Compressed LOAD and STORE are again exactly the same as scalar LOAD/STORE,
1426 where the same rules apply and the same pseudo-code apply as for
1427 non-compressed LOAD/STORE. Again: setting scalar or vector mode
1428 on the src for LOAD and dest for STORE switches mode from "Unit Stride"
1429 to "Multi-indirection", respectively.
1431 # Element bitwidth polymorphism <a name="elwidth"></a>
1433 Element bitwidth is best covered as its own special section, as it
1434 is quite involved and applies uniformly across-the-board. SV restricts
1435 bitwidth polymorphism to default, 8-bit, 16-bit and 32-bit.
1437 The effect of setting an element bitwidth is to re-cast each entry
1438 in the register table, and for all memory operations involving
1439 load/stores of certain specific sizes, to a completely different width.
1440 Thus In c-style terms, on an RV64 architecture, effectively each register
1441 now looks like this:
1450 // integer table: assume maximum SV 7-bit regfile size
1451 reg_t int_regfile[128];
1453 where the CSR Register table entry (not the instruction alone) determines
1454 which of those union entries is to be used on each operation, and the
1455 VL element offset in the hardware-loop specifies the index into each array.
1457 However a naive interpretation of the data structure above masks the
1458 fact that setting VL greater than 8, for example, when the bitwidth is 8,
1459 accessing one specific register "spills over" to the following parts of
1460 the register file in a sequential fashion. So a much more accurate way
1461 to reflect this would be:
1464 uint8_t actual_bytes[8]; // 8 for RV64, 4 for RV32, 16 for RV128
1465 uint8_t b[0]; // array of type uint8_t
1472 reg_t int_regfile[128];
1474 where when accessing any individual regfile[n].b entry it is permitted
1475 (in c) to arbitrarily over-run the *declared* length of the array (zero),
1476 and thus "overspill" to consecutive register file entries in a fashion
1477 that is completely transparent to a greatly-simplified software / pseudo-code
1479 It is however critical to note that it is clearly the responsibility of
1480 the implementor to ensure that, towards the end of the register file,
1481 an exception is thrown if attempts to access beyond the "real" register
1482 bytes is ever attempted.
1484 Now we may modify pseudo-code an operation where all element bitwidths have
1485 been set to the same size, where this pseudo-code is otherwise identical
1486 to its "non" polymorphic versions (above):
1488 function op_add(rd, rs1, rs2) # add not VADD!
1491 for (i = 0; i < VL; i++)
1494 // TODO, calculate if over-run occurs, for each elwidth
1496 int_regfile[rd].b[id] <= int_regfile[rs1].i[irs1] +
1497 int_regfile[rs2].i[irs2];
1498 } else if elwidth == 16 {
1499 int_regfile[rd].s[id] <= int_regfile[rs1].s[irs1] +
1500 int_regfile[rs2].s[irs2];
1501 } else if elwidth == 32 {
1502 int_regfile[rd].i[id] <= int_regfile[rs1].i[irs1] +
1503 int_regfile[rs2].i[irs2];
1504 } else { // elwidth == 64
1505 int_regfile[rd].l[id] <= int_regfile[rs1].l[irs1] +
1506 int_regfile[rs2].l[irs2];
1511 So here we can see clearly: for 8-bit entries rd, rs1 and rs2 (and registers
1512 following sequentially on respectively from the same) are "type-cast"
1513 to 8-bit; for 16-bit entries likewise and so on.
1515 However that only covers the case where the element widths are the same.
1516 Where the element widths are different, the following algorithm applies:
1518 * Analyse the bitwidth of all source operands and work out the
1519 maximum. Record this as "maxsrcbitwidth"
1520 * If any given source operand requires sign-extension or zero-extension
1521 (ldb, div, rem, mul, sll, srl, sra etc.), instead of mandatory 32-bit
1522 sign-extension / zero-extension or whatever is specified in the standard
1523 RV specification, **change** that to sign-extending from the respective
1524 individual source operand's bitwidth from the CSR table out to
1525 "maxsrcbitwidth" (previously calculated), instead.
1526 * Following separate and distinct (optional) sign/zero-extension of all
1527 source operands as specifically required for that operation, carry out the
1528 operation at "maxsrcbitwidth". (Note that in the case of LOAD/STORE or MV
1529 this may be a "null" (copy) operation, and that with FCVT, the changes
1530 to the source and destination bitwidths may also turn FVCT effectively
1532 * If the destination operand requires sign-extension or zero-extension,
1533 instead of a mandatory fixed size (typically 32-bit for arithmetic,
1534 for subw for example, and otherwise various: 8-bit for sb, 16-bit for sw
1535 etc.), overload the RV specification with the bitwidth from the
1536 destination register's elwidth entry.
1537 * Finally, store the (optionally) sign/zero-extended value into its
1538 destination: memory for sb/sw etc., or an offset section of the register
1539 file for an arithmetic operation.
1541 In this way, polymorphic bitwidths are achieved without requiring a
1542 massive 64-way permutation of calculations **per opcode**, for example
1543 (4 possible rs1 bitwidths times 4 possible rs2 bitwidths times 4 possible
1544 rd bitwidths). The pseudo-code is therefore as follows:
1563 get_max_elwidth(rs1, rs2):
1564 return max(bw(int_csr[rs1].elwidth), # default (XLEN) if not set
1565 bw(int_csr[rs2].elwidth)) # again XLEN if no entry
1567 get_polymorphed_reg(reg, bitwidth, offset):
1569 res.l = 0; // TODO: going to need sign-extending / zero-extending
1571 reg.b = int_regfile[reg].b[offset]
1572 elif bitwidth == 16:
1573 reg.s = int_regfile[reg].s[offset]
1574 elif bitwidth == 32:
1575 reg.i = int_regfile[reg].i[offset]
1576 elif bitwidth == 64:
1577 reg.l = int_regfile[reg].l[offset]
1580 set_polymorphed_reg(reg, bitwidth, offset, val):
1581 if (!int_csr[reg].isvec):
1582 # sign/zero-extend depending on opcode requirements, from
1583 # the reg's bitwidth out to the full bitwidth of the regfile
1584 val = sign_or_zero_extend(val, bitwidth, xlen)
1585 int_regfile[reg].l[0] = val
1587 int_regfile[reg].b[offset] = val
1588 elif bitwidth == 16:
1589 int_regfile[reg].s[offset] = val
1590 elif bitwidth == 32:
1591 int_regfile[reg].i[offset] = val
1592 elif bitwidth == 64:
1593 int_regfile[reg].l[offset] = val
1595 maxsrcwid = get_max_elwidth(rs1, rs2) # source element width(s)
1596 destwid = int_csr[rs1].elwidth # destination element width
1597 for (i = 0; i < VL; i++)
1598 if (predval & 1<<i) # predication uses intregs
1599 // TODO, calculate if over-run occurs, for each elwidth
1600 src1 = get_polymorphed_reg(rs1, maxsrcwid, irs1)
1601 // TODO, sign/zero-extend src1 and src2 as operation requires
1602 if (op_requires_sign_extend_src1)
1603 src1 = sign_extend(src1, maxsrcwid)
1604 src2 = get_polymorphed_reg(rs2, maxsrcwid, irs2)
1605 result = src1 + src2 # actual add here
1606 // TODO, sign/zero-extend result, as operation requires
1607 if (op_requires_sign_extend_dest)
1608 result = sign_extend(result, maxsrcwid)
1609 set_polymorphed_reg(rd, destwid, ird, result)
1610 if (!int_vec[rd].isvector) break
1611 if (int_vec[rd ].isvector) { id += 1; }
1612 if (int_vec[rs1].isvector) { irs1 += 1; }
1613 if (int_vec[rs2].isvector) { irs2 += 1; }
1615 Whilst specific sign-extension and zero-extension pseudocode call
1616 details are left out, due to each operation being different, the above
1617 should be clear that;
1619 * the source operands are extended out to the maximum bitwidth of all
1621 * the operation takes place at that maximum source bitwidth (the
1622 destination bitwidth is not involved at this point, at all)
1623 * the result is extended (or potentially even, truncated) before being
1624 stored in the destination. i.e. truncation (if required) to the
1625 destination width occurs **after** the operation **not** before.
1626 * when the destination is not marked as "vectorised", the **full**
1627 (standard, scalar) register file entry is taken up, i.e. the
1628 element is either sign-extended or zero-extended to cover the
1629 full register bitwidth (XLEN) if it is not already XLEN bits long.
1631 Implementors are entirely free to optimise the above, particularly
1632 if it is specifically known that any given operation will complete
1633 accurately in less bits, as long as the results produced are
1634 directly equivalent and equal, for all inputs and all outputs,
1635 to those produced by the above algorithm.
1637 ## Polymorphic floating-point operation exceptions and error-handling
1639 For floating-point operations, conversion takes place without
1640 raising any kind of exception. Exactly as specified in the standard
1641 RV specification, NAN (or appropriate) is stored if the result
1642 is beyond the range of the destination, and, again, exactly as
1643 with the standard RV specification just as with scalar
1644 operations, the floating-point flag is raised (FCSR). And, again, just as
1645 with scalar operations, it is software's responsibility to check this flag.
1646 Given that the FCSR flags are "accrued", the fact that multiple element
1647 operations could have occurred is not a problem.
1649 Note that it is perfectly legitimate for floating-point bitwidths of
1650 only 8 to be specified. However whilst it is possible to apply IEEE 754
1651 principles, no actual standard yet exists. Implementors wishing to
1652 provide hardware-level 8-bit support rather than throw a trap to emulate
1653 in software should contact the author of this specification before
1656 ## Polymorphic shift operators
1658 A special note is needed for changing the element width of left and right
1659 shift operators, particularly right-shift. Even for standard RV base,
1660 in order for correct results to be returned, the second operand RS2 must
1661 be truncated to be within the range of RS1's bitwidth. spike's implementation
1662 of sll for example is as follows:
1664 WRITE_RD(sext_xlen(zext_xlen(RS1) << (RS2 & (xlen-1))));
1666 which means: where XLEN is 32 (for RV32), restrict RS2 to cover the
1667 range 0..31 so that RS1 will only be left-shifted by the amount that
1668 is possible to fit into a 32-bit register. Whilst this appears not
1669 to matter for hardware, it matters greatly in software implementations,
1670 and it also matters where an RV64 system is set to "RV32" mode, such
1671 that the underlying registers RS1 and RS2 comprise 64 hardware bits
1674 For SV, where each operand's element bitwidth may be over-ridden, the
1675 rule about determining the operation's bitwidth *still applies*, being
1676 defined as the maximum bitwidth of RS1 and RS2. *However*, this rule
1677 **also applies to the truncation of RS2**. In other words, *after*
1678 determining the maximum bitwidth, RS2's range must **also be truncated**
1679 to ensure a correct answer. Example:
1681 * RS1 is over-ridden to a 16-bit width
1682 * RS2 is over-ridden to an 8-bit width
1683 * RD is over-ridden to a 64-bit width
1684 * the maximum bitwidth is thus determined to be 16-bit - max(8,16)
1685 * RS2 is **truncated to a range of values from 0 to 15**: RS2 & (16-1)
1687 Pseudocode (in spike) for this example would therefore be:
1689 WRITE_RD(sext_xlen(zext_16bit(RS1) << (RS2 & (16-1))));
1691 This example illustrates that considerable care therefore needs to be
1692 taken to ensure that left and right shift operations are implemented
1693 correctly. The key is that
1695 * The operation bitwidth is determined by the maximum bitwidth
1696 of the *source registers*, **not** the destination register bitwidth
1697 * The result is then sign-extend (or truncated) as appropriate.
1699 ## Polymorphic MULH/MULHU/MULHSU
1701 MULH is designed to take the top half MSBs of a multiply that
1702 does not fit within the range of the source operands, such that
1703 smaller width operations may produce a full double-width multiply
1704 in two cycles. The issue is: SV allows the source operands to
1705 have variable bitwidth.
1707 Here again special attention has to be paid to the rules regarding
1708 bitwidth, which, again, are that the operation is performed at
1709 the maximum bitwidth of the **source** registers. Therefore:
1711 * An 8-bit x 8-bit multiply will create a 16-bit result that must
1712 be shifted down by 8 bits
1713 * A 16-bit x 8-bit multiply will create a 24-bit result that must
1714 be shifted down by 16 bits (top 8 bits being zero)
1715 * A 16-bit x 16-bit multiply will create a 32-bit result that must
1716 be shifted down by 16 bits
1717 * A 32-bit x 16-bit multiply will create a 48-bit result that must
1718 be shifted down by 32 bits
1719 * A 32-bit x 8-bit multiply will create a 40-bit result that must
1720 be shifted down by 32 bits
1722 So again, just as with shift-left and shift-right, the result
1723 is shifted down by the maximum of the two source register bitwidths.
1724 And, exactly again, truncation or sign-extension is performed on the
1725 result. If sign-extension is to be carried out, it is performed
1726 from the same maximum of the two source register bitwidths out
1727 to the result element's bitwidth.
1729 If truncation occurs, i.e. the top MSBs of the result are lost,
1730 this is "Officially Not Our Problem", i.e. it is assumed that the
1731 programmer actually desires the result to be truncated. i.e. if the
1732 programmer wanted all of the bits, they would have set the destination
1733 elwidth to accommodate them.
1735 ## Polymorphic elwidth on LOAD/STORE <a name="elwidth_loadstore"></a>
1737 Polymorphic element widths in vectorised form means that the data
1738 being loaded (or stored) across multiple registers needs to be treated
1739 (reinterpreted) as a contiguous stream of elwidth-wide items, where
1740 the source register's element width is **independent** from the destination's.
1742 This makes for a slightly more complex algorithm when using indirection
1743 on the "addressed" register (source for LOAD and destination for STORE),
1744 particularly given that the LOAD/STORE instruction provides important
1745 information about the width of the data to be reinterpreted.
1747 Let's illustrate the "load" part, where the pseudo-code for elwidth=default
1748 was as follows, and i is the loop from 0 to VL-1:
1750 srcbase = ireg[rs+i];
1751 return mem[srcbase + imm]; // returns XLEN bits
1753 Instead, when elwidth != default, for a LW (32-bit LOAD), elwidth-wide
1754 chunks are taken from the source memory location addressed by the current
1755 indexed source address register, and only when a full 32-bits-worth
1756 are taken will the index be moved on to the next contiguous source
1759 bitwidth = bw(elwidth); // source elwidth from CSR reg entry
1760 elsperblock = 32 / bitwidth // 1 if bw=32, 2 if bw=16, 4 if bw=8
1761 srcbase = ireg[rs+i/(elsperblock)]; // integer divide
1762 offs = i % elsperblock; // modulo
1763 return &mem[srcbase + imm + offs]; // re-cast to uint8_t*, uint16_t* etc.
1765 Note that the constant "32" above is replaced by 8 for LB, 16 for LH, 64 for LD
1768 The principle is basically exactly the same as if the srcbase were pointing
1769 at the memory of the *register* file: memory is re-interpreted as containing
1770 groups of elwidth-wide discrete elements.
1772 When storing the result from a load, it's important to respect the fact
1773 that the destination register has its *own separate element width*. Thus,
1774 when each element is loaded (at the source element width), any sign-extension
1775 or zero-extension (or truncation) needs to be done to the *destination*
1776 bitwidth. Also, the storing has the exact same analogous algorithm as
1777 above, where in fact it is just the set\_polymorphed\_reg pseudocode
1778 (completely unchanged) used above.
1780 One issue remains: when the source element width is **greater** than
1781 the width of the operation, it is obvious that a single LB for example
1782 cannot possibly obtain 16-bit-wide data. This condition may be detected
1783 where, when using integer divide, elsperblock (the width of the LOAD
1784 divided by the bitwidth of the element) is zero.
1786 The issue is "fixed" by ensuring that elsperblock is a minimum of 1:
1788 elsperblock = min(1, LD_OP_BITWIDTH / element_bitwidth)
1790 The elements, if the element bitwidth is larger than the LD operation's
1791 size, will then be sign/zero-extended to the full LD operation size, as
1792 specified by the LOAD (LDU instead of LD, LBU instead of LB), before
1793 being passed on to the second phase.
1795 As LOAD/STORE may be twin-predicated, it is important to note that
1796 the rules on twin predication still apply, except where in previous
1797 pseudo-code (elwidth=default for both source and target) it was
1798 the *registers* that the predication was applied to, it is now the
1799 **elements** that the predication is applied to.
1801 Thus the full pseudocode for all LD operations may be written out
1804 function LBU(rd, rs):
1805 load_elwidthed(rd, rs, 8, true)
1806 function LB(rd, rs):
1807 load_elwidthed(rd, rs, 8, false)
1808 function LH(rd, rs):
1809 load_elwidthed(rd, rs, 16, false)
1812 function LQ(rd, rs):
1813 load_elwidthed(rd, rs, 128, false)
1815 # returns 1 byte of data when opwidth=8, 2 bytes when opwidth=16..
1816 function load_memory(rs, imm, i, opwidth):
1817 elwidth = int_csr[rs].elwidth
1818 bitwidth = bw(elwidth);
1819 elsperblock = min(1, opwidth / bitwidth)
1820 srcbase = ireg[rs+i/(elsperblock)];
1821 offs = i % elsperblock;
1822 return mem[srcbase + imm + offs]; # 1/2/4/8/16 bytes
1824 function load_elwidthed(rd, rs, opwidth, unsigned):
1825 destwid = int_csr[rd].elwidth # destination element width
1826 rd = int_csr[rd].active ? int_csr[rd].regidx : rd;
1827 rs = int_csr[rs].active ? int_csr[rs].regidx : rs;
1828 ps = get_pred_val(FALSE, rs); # predication on src
1829 pd = get_pred_val(FALSE, rd); # ... AND on dest
1830 for (int i = 0, int j = 0; i < VL && j < VL;):
1831 if (int_csr[rs].isvec) while (!(ps & 1<<i)) i++;
1832 if (int_csr[rd].isvec) while (!(pd & 1<<j)) j++;
1833 val = load_memory(rs, imm, i, opwidth)
1835 val = zero_extend(val, min(opwidth, bitwidth))
1837 val = sign_extend(val, min(opwidth, bitwidth))
1838 set_polymorphed_reg(rd, bitwidth, j, val)
1839 if (int_csr[rs].isvec) i++;
1840 if (int_csr[rd].isvec) j++; else break;
1844 * when comparing against for example the twin-predicated c.mv
1845 pseudo-code, the pattern of independent incrementing of rd and rs
1846 is preserved unchanged.
1847 * just as with the c.mv pseudocode, zeroing is not included and must be
1848 taken into account (TODO).
1849 * that due to the use of a twin-predication algorithm, LOAD/STORE also
1850 take on the same VSPLAT, VINSERT, VREDUCE, VEXTRACT, VGATHER and
1851 VSCATTER characteristics.
1852 * that due to the use of the same set\_polymorphed\_reg pseudocode,
1853 a destination that is not vectorised (marked as scalar) will
1854 result in the element being fully sign-extended or zero-extended
1855 out to the full register file bitwidth (XLEN). When the source
1856 is also marked as scalar, this is how the compatibility with
1857 standard RV LOAD/STORE is preserved by this algorithm.
1859 ### Example Tables showing LOAD elements
1861 This section contains examples of vectorised LOAD operations, showing
1862 how the two stage process works (three if zero/sign-extension is included).
1865 #### Example: LD x8, x5(0), x8 CSR-elwidth=32, x5 CSR-elwidth=16, VL=7
1869 * a 64-bit load, with an offset of zero
1870 * with a source-address elwidth of 16-bit
1871 * into a destination-register with an elwidth of 32-bit
1873 * from register x5 (actually x5-x6) to x8 (actually x8 to half of x11)
1874 * RV64, where XLEN=64 is assumed.
1876 First, the memory table, which, due to the
1877 element width being 16 and the operation being LD (64), the 64-bits
1878 loaded from memory are subdivided into groups of **four** elements.
1879 And, with VL being 7 (deliberately to illustrate that this is reasonable
1880 and possible), the first four are sourced from the offset addresses pointed
1881 to by x5, and the next three from the ofset addresses pointed to by
1882 the next contiguous register, x6:
1885 addr | byte 0 | byte 1 | byte 2 | byte 3 | byte 4 | byte 5 | byte 6 | byte 7 |
1886 @x5 | elem 0 || elem 1 || elem 2 || elem 3 ||
1887 @x6 | elem 4 || elem 5 || elem 6 || not loaded ||
1890 Next, the elements are zero-extended from 16-bit to 32-bit, as whilst
1891 the elwidth CSR entry for x5 is 16-bit, the destination elwidth on x8 is 32.
1894 byte 3 | byte 2 | byte 1 | byte 0 |
1895 0x0 | 0x0 | elem0 ||
1896 0x0 | 0x0 | elem1 ||
1897 0x0 | 0x0 | elem2 ||
1898 0x0 | 0x0 | elem3 ||
1899 0x0 | 0x0 | elem4 ||
1900 0x0 | 0x0 | elem5 ||
1901 0x0 | 0x0 | elem6 ||
1902 0x0 | 0x0 | elem7 ||
1905 Lastly, the elements are stored in contiguous blocks, as if x8 was also
1906 byte-addressable "memory". That "memory" happens to cover registers
1907 x8, x9, x10 and x11, with the last 32 "bits" of x11 being **UNMODIFIED**:
1910 reg# | byte 7 | byte 6 | byte 5 | byte 4 | byte 3 | byte 2 | byte 1 | byte 0 |
1911 x8 | 0x0 | 0x0 | elem 1 || 0x0 | 0x0 | elem 0 ||
1912 x9 | 0x0 | 0x0 | elem 3 || 0x0 | 0x0 | elem 2 ||
1913 x10 | 0x0 | 0x0 | elem 5 || 0x0 | 0x0 | elem 4 ||
1914 x11 | **UNMODIFIED** |||| 0x0 | 0x0 | elem 6 ||
1917 Thus we have data that is loaded from the **addresses** pointed to by
1918 x5 and x6, zero-extended from 16-bit to 32-bit, stored in the **registers**
1919 x8 through to half of x11.
1920 The end result is that elements 0 and 1 end up in x8, with element 8 being
1921 shifted up 32 bits, and so on, until finally element 6 is in the
1924 Note that whilst the memory addressing table is shown left-to-right byte order,
1925 the registers are shown in right-to-left (MSB) order. This does **not**
1926 imply that bit or byte-reversal is carried out: it's just easier to visualise
1927 memory as being contiguous bytes, and emphasises that registers are not
1928 really actually "memory" as such.
1930 ## Why SV bitwidth specification is restricted to 4 entries
1932 The four entries for SV element bitwidths only allows three over-rides:
1938 This would seem inadequate, surely it would be better to have 3 bits or
1939 more and allow 64, 128 and some other options besides. The answer here
1940 is, it gets too complex, no RV128 implementation yet exists, and so RV64's
1941 default is 64 bit, so the 4 major element widths are covered anyway.
1943 There is an absolutely crucial aspect oF SV here that explicitly
1944 needs spelling out, and it's whether the "vectorised" bit is set in
1945 the Register's CSR entry.
1947 If "vectorised" is clear (not set), this indicates that the operation
1948 is "scalar". Under these circumstances, when set on a destination (RD),
1949 then sign-extension and zero-extension, whilst changed to match the
1950 override bitwidth (if set), will erase the **full** register entry
1953 When vectorised is *set*, this indicates that the operation now treats
1954 **elements** as if they were independent registers, so regardless of
1955 the length, any parts of a given actual register that are not involved
1956 in the operation are **NOT** modified, but are **PRESERVED**.
1960 * when the vector bit is clear and elwidth set to 16 on the destination
1961 register, operations are truncated to 16 bit and then sign or zero
1962 extended to the *FULL* XLEN register width.
1963 * when the vector bit is set, elwidth is 16 and VL=1 (or other value where
1964 groups of elwidth sized elements do not fill an entire XLEN register),
1965 the "top" bits of the destination register do *NOT* get modified, zero'd
1966 or otherwise overwritten.
1968 SIMD micro-architectures may implement this by using predication on
1969 any elements in a given actual register that are beyond the end of
1970 multi-element operation.
1972 Other microarchitectures may choose to provide byte-level write-enable
1973 lines on the register file, such that each 64 bit register in an RV64
1974 system requires 8 WE lines. Scalar RV64 operations would require
1975 activation of all 8 lines, where SV elwidth based operations would
1976 activate the required subset of those byte-level write lines.
1980 * rs1, rs2 and rd are all set to 8-bit
1982 * RV64 architecture is set (UXL=64)
1983 * add operation is carried out
1984 * bits 0-23 of RD are modified to be rs1[23..16] + rs2[23..16]
1985 concatenated with similar add operations on bits 15..8 and 7..0
1986 * bits 24 through 63 **remain as they originally were**.
1988 Example SIMD micro-architectural implementation:
1990 * SIMD architecture works out the nearest round number of elements
1991 that would fit into a full RV64 register (in this case: 8)
1992 * SIMD architecture creates a hidden predicate, binary 0b00000111
1993 i.e. the bottom 3 bits set (VL=3) and the top 5 bits clear
1994 * SIMD architecture goes ahead with the add operation as if it
1995 was a full 8-wide batch of 8 adds
1996 * SIMD architecture passes top 5 elements through the adders
1997 (which are "disabled" due to zero-bit predication)
1998 * SIMD architecture gets the 5 unmodified top 8-bits back unmodified
1999 and stores them in rd.
2001 This requires a read on rd, however this is required anyway in order
2002 to support non-zeroing mode.
2004 ## Polymorphic floating-point
2006 Standard scalar RV integer operations base the register width on XLEN,
2007 which may be changed (UXL in USTATUS, and the corresponding MXL and
2008 SXL in MSTATUS and SSTATUS respectively). Integer LOAD, STORE and
2009 arithmetic operations are therefore restricted to an active XLEN bits,
2010 with sign or zero extension to pad out the upper bits when XLEN has
2011 been dynamically set to less than the actual register size.
2013 For scalar floating-point, the active (used / changed) bits are
2014 specified exclusively by the operation: ADD.S specifies an active
2015 32-bits, with the upper bits of the source registers needing to
2016 be all 1s ("NaN-boxed"), and the destination upper bits being
2017 *set* to all 1s (including on LOAD/STOREs).
2019 Where elwidth is set to default (on any source or the destination)
2020 it is obvious that this NaN-boxing behaviour can and should be
2021 preserved. When elwidth is non-default things are less obvious,
2022 so need to be thought through. Here is a normal (scalar) sequence,
2023 assuming an RV64 which supports Quad (128-bit) FLEN:
2025 * FLD loads 64-bit wide from memory. Top 64 MSBs are set to all 1s
2026 * ADD.D performs a 64-bit-wide add. Top 64 MSBs of destination set to 1s.
2027 * FSD stores lowest 64-bits from the 128-bit-wide register to memory:
2028 top 64 MSBs ignored.
2030 Therefore it makes sense to mirror this behaviour when, for example,
2031 elwidth is set to 32. Assume elwidth set to 32 on all source and
2032 destination registers:
2034 * FLD loads 64-bit wide from memory as **two** 32-bit single-precision
2035 floating-point numbers.
2036 * ADD.D performs **two** 32-bit-wide adds, storing one of the adds
2037 in bits 0-31 and the second in bits 32-63.
2038 * FSD stores lowest 64-bits from the 128-bit-wide register to memory
2040 Here's the thing: it does not make sense to overwrite the top 64 MSBs
2041 of the registers either during the FLD **or** the ADD.D. The reason
2042 is that, effectively, the top 64 MSBs actually represent a completely
2043 independent 64-bit register, so overwriting it is not only gratuitous
2044 but may actually be harmful for a future extension to SV which may
2045 have a way to directly access those top 64 bits.
2047 The decision is therefore **not** to touch the upper parts of floating-point
2048 registers whereever elwidth is set to non-default values, including
2049 when "isvec" is false in a given register's CSR entry. Only when the
2050 elwidth is set to default **and** isvec is false will the standard
2051 RV behaviour be followed, namely that the upper bits be modified.
2053 Ultimately if elwidth is default and isvec false on *all* source
2054 and destination registers, a SimpleV instruction defaults completely
2055 to standard RV scalar behaviour (this holds true for **all** operations,
2056 right across the board).
2058 The nice thing here is that ADD.S, ADD.D and ADD.Q when elwidth are
2059 non-default values are effectively all the same: they all still perform
2060 multiple ADD operations, just at different widths. A future extension
2061 to SimpleV may actually allow ADD.S to access the upper bits of the
2062 register, effectively breaking down a 128-bit register into a bank
2063 of 4 independently-accesible 32-bit registers.
2065 In the meantime, although when e.g. setting VL to 8 it would technically
2066 make no difference to the ALU whether ADD.S, ADD.D or ADD.Q is used,
2067 using ADD.Q may be an easy way to signal to the microarchitecture that
2068 it is to receive a higher VL value. On a superscalar OoO architecture
2069 there may be absolutely no difference, however on simpler SIMD-style
2070 microarchitectures they may not necessarily have the infrastructure in
2071 place to know the difference, such that when VL=8 and an ADD.D instruction
2072 is issued, it completes in 2 cycles (or more) rather than one, where
2073 if an ADD.Q had been issued instead on such simpler microarchitectures
2074 it would complete in one.
2076 ## Specific instruction walk-throughs
2078 This section covers walk-throughs of the above-outlined procedure
2079 for converting standard RISC-V scalar arithmetic operations to
2080 polymorphic widths, to ensure that it is correct.
2084 Standard Scalar RV32/RV64 (xlen):
2091 Polymorphic variant:
2093 * RS1 @ rs1 bits, zero-extended to max(rs1, rs2) bits
2094 * RS2 @ rs2 bits, zero-extended to max(rs1, rs2) bits
2095 * add @ max(rs1, rs2) bits
2096 * RD @ rd bits. zero-extend to rd if rd > max(rs1, rs2) otherwise truncate
2098 Note here that polymorphic add zero-extends its source operands,
2099 where addw sign-extends.
2103 The RV Specification specifically states that "W" variants of arithmetic
2104 operations always produce 32-bit signed values. In a polymorphic
2105 environment it is reasonable to assume that the signed aspect is
2106 preserved, where it is the length of the operands and the result
2107 that may be changed.
2109 Standard Scalar RV64 (xlen):
2114 * RD @ xlen bits, truncate add to 32-bit and sign-extend to xlen.
2116 Polymorphic variant:
2118 * RS1 @ rs1 bits, sign-extended to max(rs1, rs2) bits
2119 * RS2 @ rs2 bits, sign-extended to max(rs1, rs2) bits
2120 * add @ max(rs1, rs2) bits
2121 * RD @ rd bits. sign-extend to rd if rd > max(rs1, rs2) otherwise truncate
2123 Note here that polymorphic addw sign-extends its source operands,
2124 where add zero-extends.
2126 This requires a little more in-depth analysis. Where the bitwidth of
2127 rs1 equals the bitwidth of rs2, no sign-extending will occur. It is
2128 only where the bitwidth of either rs1 or rs2 are different, will the
2129 lesser-width operand be sign-extended.
2131 Effectively however, both rs1 and rs2 are being sign-extended (or truncated),
2132 where for add they are both zero-extended. This holds true for all arithmetic
2133 operations ending with "W".
2137 Standard Scalar RV64I:
2139 * RS1 @ xlen bits, truncated to 32-bit
2140 * immed @ 12 bits, sign-extended to 32-bit
2142 * RD @ rd bits. sign-extend to rd if rd > 32, otherwise truncate.
2144 Polymorphic variant:
2147 * immed @ 12 bits, sign-extend to max(rs1, 12) bits
2148 * add @ max(rs1, 12) bits
2149 * RD @ rd bits. sign-extend to rd if rd > max(rs1, 12) otherwise truncate
2151 # Predication Element Zeroing
2153 The introduction of zeroing on traditional vector predication is usually
2154 intended as an optimisation for lane-based microarchitectures with register
2155 renaming to be able to save power by avoiding a register read on elements
2156 that are passed through en-masse through the ALU. Simpler microarchitectures
2157 do not have this issue: they simply do not pass the element through to
2158 the ALU at all, and therefore do not store it back in the destination.
2159 More complex non-lane-based micro-architectures can, when zeroing is
2160 not set, use the predication bits to simply avoid sending element-based
2161 operations to the ALUs, entirely: thus, over the long term, potentially
2162 keeping all ALUs 100% occupied even when elements are predicated out.
2164 SimpleV's design principle is not based on or influenced by
2165 microarchitectural design factors: it is a hardware-level API.
2166 Therefore, looking purely at whether zeroing is *useful* or not,
2167 (whether less instructions are needed for certain scenarios),
2168 given that a case can be made for zeroing *and* non-zeroing, the
2169 decision was taken to add support for both.
2171 ## Single-predication (based on destination register)
2173 Zeroing on predication for arithmetic operations is taken from
2174 the destination register's predicate. i.e. the predication *and*
2175 zeroing settings to be applied to the whole operation come from the
2176 CSR Predication table entry for the destination register.
2177 Thus when zeroing is set on predication of a destination element,
2178 if the predication bit is clear, then the destination element is *set*
2179 to zero (twin-predication is slightly different, and will be covered
2182 Thus the pseudo-code loop for a predicated arithmetic operation
2183 is modified to as follows:
2185 for (i = 0; i < VL; i++)
2186 if not zeroing: # an optimisation
2187 while (!(predval & 1<<i) && i < VL)
2188 if (int_vec[rd ].isvector) { id += 1; }
2189 if (int_vec[rs1].isvector) { irs1 += 1; }
2190 if (int_vec[rs2].isvector) { irs2 += 1; }
2197 result = src1 + src2 # actual add (or other op) here
2198 set_polymorphed_reg(rd, destwid, ird, result)
2199 if (!int_vec[rd].isvector) break
2202 set_polymorphed_reg(rd, destwid, ird, result)
2203 if (int_vec[rd ].isvector) { id += 1; }
2204 else if (predval & 1<<i) break;
2205 if (int_vec[rs1].isvector) { irs1 += 1; }
2206 if (int_vec[rs2].isvector) { irs2 += 1; }
2208 The optimisation to skip elements entirely is only possible for certain
2209 micro-architectures when zeroing is not set. However for lane-based
2210 micro-architectures this optimisation may not be practical, as it
2211 implies that elements end up in different "lanes". Under these
2212 circumstances it is perfectly fine to simply have the lanes
2213 "inactive" for predicated elements, even though it results in
2214 less than 100% ALU utilisation.
2216 ## Twin-predication (based on source and destination register)
2218 Twin-predication is not that much different, except that that
2219 the source is independently zero-predicated from the destination.
2220 This means that the source may be zero-predicated *or* the
2221 destination zero-predicated *or both*, or neither.
2223 When with twin-predication, zeroing is set on the source and not
2224 the destination, if a predicate bit is set it indicates that a zero
2225 data element is passed through the operation (the exception being:
2226 if the source data element is to be treated as an address - a LOAD -
2227 then the data returned *from* the LOAD is zero, rather than looking up an
2230 When zeroing is set on the destination and not the source, then just
2231 as with single-predicated operations, a zero is stored into the destination
2232 element (or target memory address for a STORE).
2234 Zeroing on both source and destination effectively result in a bitwise
2235 NOR operation of the source and destination predicate: the result is that
2236 where either source predicate OR destination predicate is set to 0,
2237 a zero element will ultimately end up in the destination register.
2239 However: this may not necessarily be the case for all operations;
2240 implementors, particularly of custom instructions, clearly need to
2241 think through the implications in each and every case.
2243 Here is pseudo-code for a twin zero-predicated operation:
2245 function op_mv(rd, rs) # MV not VMV!
2246 rd = int_csr[rd].active ? int_csr[rd].regidx : rd;
2247 rs = int_csr[rs].active ? int_csr[rs].regidx : rs;
2248 ps, zerosrc = get_pred_val(FALSE, rs); # predication on src
2249 pd, zerodst = get_pred_val(FALSE, rd); # ... AND on dest
2250 for (int i = 0, int j = 0; i < VL && j < VL):
2251 if (int_csr[rs].isvec && !zerosrc) while (!(ps & 1<<i)) i++;
2252 if (int_csr[rd].isvec && !zerodst) while (!(pd & 1<<j)) j++;
2255 sourcedata = ireg[rs+i];
2258 ireg[rd+j] <= sourcedata
2261 if (int_csr[rs].isvec)
2263 if (int_csr[rd].isvec)
2269 Note that in the instance where the destination is a scalar, the hardware
2270 loop is ended the moment a value *or a zero* is placed into the destination
2271 register/element. Also note that, for clarity, variable element widths
2272 have been left out of the above.
2276 TODO: expand. Exceptions may occur at any time, in any given underlying
2277 scalar operation. This implies that context-switching (traps) may
2278 occur, and operation must be returned to where it left off. That in
2279 turn implies that the full state - including the current parallel
2280 element being processed - has to be saved and restored. This is
2281 what the **STATE** CSR is for.
2283 The implications are that all underlying individual scalar operations
2284 "issued" by the parallelisation have to appear to be executed sequentially.
2285 The further implications are that if two or more individual element
2286 operations are underway, and one with an earlier index causes an exception,
2287 it may be necessary for the microarchitecture to **discard** or terminate
2288 operations with higher indices.
2290 This being somewhat dissatisfactory, an "opaque predication" variant
2291 of the STATE CSR is being considered.
2295 A "HINT" is an operation that has no effect on architectural state,
2296 where its use may, by agreed convention, give advance notification
2297 to the microarchitecture: branch prediction notification would be
2298 a good example. Usually HINTs are where rd=x0.
2300 With Simple-V being capable of issuing *parallel* instructions where
2301 rd=x0, the space for possible HINTs is expanded considerably. VL
2302 could be used to indicate different hints. In addition, if predication
2303 is set, the predication register itself could hypothetically be passed
2304 in as a *parameter* to the HINT operation.
2306 No specific hints are yet defined in Simple-V
2308 # Vector Block Format <a name="vliw-format"></a>
2310 One issue with a former revision of SV was the setup and teardown
2311 time of the CSRs. The cost of the use of a full CSRRW (requiring LI)
2312 to set up registers and predicates was quite high. A VLIW-like format
2313 therefore makes sense, and is conceptually reminiscent of the ARM Thumb2
2318 * the standard RISC-V 80 to 192 bit encoding sequence, with bits
2319 defining the options to follow within the block
2320 * An optional VL Block (16-bit)
2321 * Optional predicate entries (8/16-bit blocks: see Predicate Table, above)
2322 * Optional register entries (8/16-bit blocks: see Register Table, above)
2323 * finally some 16/32/48 bit standard RV or SVPrefix opcodes follow.
2325 Thus, the variable-length format from Section 1.5 of the RISC-V ISA is used
2328 | base+4 ... base+2 | base | number of bits |
2329 | ------ ----------------- | ---------------- | -------------------------- |
2330 | ..xxxx xxxxxxxxxxxxxxxx | xnnnxxxxx1111111 | (80+16\*nnn)-bit, nnn!=111 |
2331 | {ops}{Pred}{Reg}{VL Block} | SV Prefix | |
2333 A suitable prefix, which fits the Expanded Instruction-Length encoding
2334 for "(80 + 16 times instruction-length)", as defined in Section 1.5
2335 of the RISC-V ISA, is as follows:
2337 | 15 | 14:12 | 11:10 | 9:8 | 7 | 6:0 |
2338 | - | ----- | ----- | ----- | --- | ------- |
2339 | vlset | 16xil | pplen | rplen | mode | 1111111 |
2341 The VL/MAXVL/SubVL Block format:
2343 | 31-30 | 29:28 | 27:22 | 21:17 - 16 |
2344 | - | ----- | ------ | ------ - - |
2345 | 0 | SubVL | VLdest | VLEN vlt |
2346 | 1 | SubVL | VLdest | VLEN |
2348 Note: this format is very similar to that used in [[sv_prefix_proposal]]
2350 If vlt is 0, VLEN is a 5 bit immediate value, offset by one (i.e
2351 a bit sequence of 0b00000 represents VL=1 and so on). If vlt is 1,
2352 it specifies the scalar register from which VL is set by this VLIW
2353 instruction group. VL, whether set from the register or the immediate,
2354 is then modified (truncated) to be MIN(VL, MAXVL), and the result stored
2355 in the scalar register specified in VLdest. If VLdest is zero, no store
2356 in the regfile occurs (however VL is still set).
2358 This option will typically be used to start vectorised loops, where
2359 the VLIW instruction effectively embeds an optional "SETSUBVL, SETVL"
2360 sequence (in compact form).
2362 When bit 15 is set to 1, MAXVL and VL are both set to the immediate,
2363 VLEN (again, offset by one), which is 6 bits in length, and the same
2364 value stored in scalar register VLdest (if that register is nonzero).
2365 A value of 0b000000 will set MAXVL=VL=1, a value of 0b000001 will
2366 set MAXVL=VL= 2 and so on.
2368 This option will typically not be used so much for loops as it will be
2369 for one-off instructions such as saving the entire register file to the
2370 stack with a single one-off Vectorised and predicated LD/ST, or as a way
2371 to save or restore registers in a function call with a single instruction.
2382 * Bit 7 specifies if the prefix block format is the full 16 bit format
2383 (1) or the compact less expressive format (0). In the 8 bit format,
2384 pplen is multiplied by 2.
2385 * 8 bit format predicate numbering is implicit and begins from x9. Thus
2386 it is critical to put blocks in the correct order as required.
2387 * Bit 7 also specifies if the register block format is 16 bit (1) or 8 bit
2388 (0). In the 8 bit format, rplen is multiplied by 2. If only an odd number
2389 of entries are needed the last may be set to 0x00, indicating "unused".
2390 * Bit 15 specifies if the VL Block is present. If set to 1, the VL Block
2391 immediately follows the VLIW instruction Prefix
2392 * Bits 8 and 9 define how many RegCam entries (0 to 3 if bit 15 is 1,
2393 otherwise 0 to 6) follow the (optional) VL Block.
2394 * Bits 10 and 11 define how many PredCam entries (0 to 3 if bit 7 is 1,
2395 otherwise 0 to 6) follow the (optional) RegCam entries
2396 * Bits 14 to 12 (IL) define the actual length of the instruction: total
2397 number of bits is 80 + 16 times IL. Standard RV32, RVC and also
2398 SVPrefix (P48/64-\*-Type) instructions fit into this space, after the
2399 (optional) VL / RegCam / PredCam entries
2400 * In any RVC or 32 Bit opcode, any registers within the VLIW-prefixed
2401 format *MUST* have the RegCam and PredCam entries applied to the
2402 operation (and the Vectorisation loop activated)
2403 * P48 and P64 opcodes do **not** take their Register or predication
2404 context from the VLIW Block tables: they do however have VL or SUBVL
2405 applied (unless VLtyp or svlen are set).
2406 * At the end of the VLIW Group, the RegCam and PredCam entries
2407 *no longer apply*. VL, MAXVL and SUBVL on the other hand remain at
2408 the values set by the last instruction (whether a CSRRW or the VL
2410 * Although an inefficient use of resources, it is fine to set the MAXVL,
2411 VL and SUBVL CSRs with standard CSRRW instructions, within a VLIW block.
2413 All this would greatly reduce the amount of space utilised by Vectorised
2414 instructions, given that 64-bit CSRRW requires 3, even 4 32-bit opcodes:
2415 the CSR itself, a LI, and the setting up of the value into the RS
2416 register of the CSR, which, again, requires a LI / LUI to get the 32
2417 bit data into the CSR. To get 64-bit data into the register in order
2418 to put it into the CSR(s), LOAD operations from memory are needed!
2420 Given that each 64-bit CSR can hold only 4x PredCAM entries (or 4 RegCAM
2421 entries), that's potentially 6 to eight 32-bit instructions, just to
2422 establish the Vector State!
2424 Not only that: even CSRRW on VL and MAXVL requires 64-bits (even more
2425 bits if VL needs to be set to greater than 32). Bear in mind that in SV,
2426 both MAXVL and VL need to be set.
2428 By contrast, the VLIW prefix is only 16 bits, the VL/MAX/SubVL block is
2429 only 16 bits, and as long as not too many predicates and register vector
2430 qualifiers are specified, several 32-bit and 16-bit opcodes can fit into
2431 the format. If the full flexibility of the 16 bit block formats are not
2432 needed, more space is saved by using the 8 bit formats.
2434 In this light, embedding the VL/MAXVL, PredCam and RegCam CSR entries
2435 into a VLIW format makes a lot of sense.
2437 Bear in mind the warning in an earlier section that use of VLtyp or svlen
2438 in a P48 or P64 opcode within a VLIW Group will result in corruption
2439 (use) of the STATE CSR, as the STATE CSR is shared with SVPrefix. To
2440 avoid this situation, the STATE CSR may be copied into a temp register
2441 and restored afterwards.
2445 * Is it necessary to stick to the RISC-V 1.5 format? Why not go with
2446 using the 15th bit to allow 80 + 16\*0bnnnn bits? Perhaps to be sane,
2447 limit to 256 bits (16 times 0-11).
2448 * Could a "hint" be used to set which operations are parallel and which
2450 * Could a new sub-instruction opcode format be used, one that does not
2451 conform precisely to RISC-V rules, but *unpacks* to RISC-V opcodes?
2452 no need for byte or bit-alignment
2453 * Could a hardware compression algorithm be deployed? Quite likely,
2454 because of the sub-execution context (sub-VLIW PC)
2456 ## Limitations on instructions.
2458 To greatly simplify implementations, it is required to treat the VLIW
2459 group as a separate sub-program with its own separate PC. The sub-pc
2460 advances separately whilst the main PC remains pointing at the beginning
2461 of the VLIW instruction (not to be confused with how VL works, which
2462 is exactly the same principle, except it is VStart in the STATE CSR
2465 This has implications, namely that a new set of CSRs identical to xepc
2466 (mepc, srpc, hepc and uepc) must be created and managed and respected
2467 as being a sub extension of the xepc set of CSRs. Thus, xepcvliw CSRs
2468 must be context switched and saved / restored in traps.
2470 The srcoffs and destoffs indices in the STATE CSR may be similarly
2471 regarded as another sub-execution context, giving in effect two sets of
2472 nested sub-levels of the RISCV Program Counter (actually, three including
2475 In addition, as xepcvliw CSRs are relative to the beginning of the VLIW
2476 block, branches MUST be restricted to within (relative to) the block,
2477 i.e. addressing is now restricted to the start (and very short) length
2480 Also: calling subroutines is inadviseable, unless they can be entirely
2481 accomplished within a block.
2483 A normal jump, normal branch and a normal function call may only be taken
2484 by letting the VLIW group end, returning to "normal" standard RV mode,
2485 and then using standard RVC, 32 bit or P48/64-\*-type opcodes.
2489 * <https://groups.google.com/d/msg/comp.arch/yIFmee-Cx-c/jRcf0evSAAAJ>
2491 # Subsets of RV functionality
2493 This section describes the differences when SV is implemented on top of
2494 different subsets of RV.
2498 It is permitted to only implement SVprefix and not the VLIW instruction
2499 format option, and vice-versa. UNIX Platforms **MUST** raise illegal
2500 instruction on seeing an unsupported VLIW or SVprefix opcode, so that
2501 traps may emulate the format.
2503 It is permitted in SVprefix to either not implement VL or not implement
2504 SUBVL (see [[sv_prefix_proposal]] for full details. Again, UNIX Platforms
2505 *MUST* raise illegal instruction on implementations that do not support
2508 It is permitted to limit the size of either (or both) the register files
2509 down to the original size of the standard RV architecture. However, below
2510 the mandatory limits set in the RV standard will result in non-compliance
2511 with the SV Specification.
2515 When RV32 or RV32F is implemented, XLEN is set to 32, and thus the
2516 maximum limit for predication is also restricted to 32 bits. Whilst not
2517 actually specifically an "option" it is worth noting.
2521 Normally in standard RV32 it does not make much sense to have
2522 RV32G, The critical instructions that are missing in standard RV32
2523 are those for moving data to and from the double-width floating-point
2524 registers into the integer ones, as well as the FCVT routines.
2526 In an earlier draft of SV, it was possible to specify an elwidth
2527 of double the standard register size: this had to be dropped,
2528 and may be reintroduced in future revisions.
2530 ## RV32 (not RV32F / RV32G) and RV64 (not RV64F / RV64G)
2532 When floating-point is not implemented, the size of the User Register and
2533 Predication CSR tables may be halved, to only 4 2x16-bit CSRs (8 entries
2538 In embedded scenarios the User Register and Predication CSRs may be
2539 dropped entirely, or optionally limited to 1 CSR, such that the combined
2540 number of entries from the M-Mode CSR Register table plus U-Mode
2541 CSR Register table is either 4 16-bit entries or (if the U-Mode is
2542 zero) only 2 16-bit entries (M-Mode CSR table only). Likewise for
2543 the Predication CSR tables.
2545 RV32E is the most likely candidate for simply detecting that registers
2546 are marked as "vectorised", and generating an appropriate exception
2547 for the VL loop to be implemented in software.
2551 RV128 has not been especially considered, here, however it has some
2552 extremely large possibilities: double the element width implies
2553 256-bit operands, spanning 2 128-bit registers each, and predication
2554 of total length 128 bit given that XLEN is now 128.
2556 # Under consideration <a name="issues"></a>
2558 for element-grouping, if there is unused space within a register
2559 (3 16-bit elements in a 64-bit register for example), recommend:
2561 * For the unused elements in an integer register, the used element
2562 closest to the MSB is sign-extended on write and the unused elements
2563 are ignored on read.
2564 * The unused elements in a floating-point register are treated as-if
2565 they are set to all ones on write and are ignored on read, matching the
2566 existing standard for storing smaller FP values in larger registers.
2572 > One solution is to just not support LR/SC wider than a fixed
2573 > implementation-dependent size, which must be at least
2574 >1 XLEN word, which can be read from a read-only CSR
2575 > that can also be used for info like the kind and width of
2576 > hw parallelism supported (128-bit SIMD, minimal virtual
2577 > parallelism, etc.) and other things (like maybe the number
2578 > of registers supported).
2580 > That CSR would have to have a flag to make a read trap so
2581 > a hypervisor can simulate different values.
2585 > And what about instructions like JALR?
2587 answer: they're not vectorised, so not a problem
2591 * if opcode is in the RV32 group, rd, rs1 and rs2 bitwidth are
2592 XLEN if elwidth==default
2593 * if opcode is in the RV32I group, rd, rs1 and rs2 bitwidth are
2594 *32* if elwidth == default
2598 TODO: document different lengths for INT / FP regfiles, and provide
2599 as part of info register. 00=32, 01=64, 10=128, 11=reserved.
2603 TODO, update to remove RegCam and PredCam CSRs, just use SVprefix and
2608 Could the 8 bit Register VLIW format use regnum<<1 instead, only accessing regs 0 to 64?
2612 Expand the range of SUBVL and its associated svsrcoffs and svdestoffs by
2613 adding a 2nd STATE CSR (or extending STATE to 64 bits). Future version?
2617 TODO evaluate strncpy and strlen
2618 <https://groups.google.com/forum/m/#!msg/comp.arch/bGBeaNjAKvc/_vbqyxTUAQAJ>
2623 mv a3, a0 # Copy dst
2625 setvli x0, a2, vint8 # Vectors of bytes.
2626 vlbff.v v1, (a1) # Get src bytes
2627 vseq.vi v0, v1, 0 # Flag zero bytes
2628 vmfirst a4, v0 # Zero found?
2629 vmsif.v v0, v0 # Set mask up to and including zero byte. Ppplio
2630 vsb.v v1, (a3), v0.t # Write out bytes
2631 bgez a4, exit # Done
2632 csrr t1, vl # Get number of bytes fetched
2633 add a1, a1, t1 # Bump src pointer
2634 sub a2, a2, t1 # Decrement count.
2635 add a3, a3, t1 # Bump dst pointer
2636 bnez a2, loop # Anymore?
2644 mv a3, a0 # Save start
2646 setvli a1, x0, vint8 # byte vec, x0 (Zero reg) => use max hardware len
2647 vldbff.v v1, (a3) # Get bytes
2648 csrr a1, vl # Get bytes actually read e.g. if fault
2649 vseq.vi v0, v1, 0 # Set v0[i] where v1[i] = 0
2650 add a3, a3, a1 # Bump pointer
2651 vmfirst a2, v0 # Find first set bit in mask, returns -1 if none
2652 bltz a2, loop # Not found?
2653 add a0, a0, a1 # Sum start + bump
2654 add a3, a3, a2 # Add index of zero byte
2655 sub a0, a3, a0 # Subtract start address+bump