X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=simple_v_extension.mdwn;h=4cf0937edde233618bbd012a4a8ad571c9acd473;hb=b51aadd82e481d25c5665179c06b544e759bed97;hp=cb2ba08fe3152665cdb7a0e419fd4f656f3a1e63;hpb=4b8778990113e96ab70f6368c01a358439466253;p=libreriscv.git diff --git a/simple_v_extension.mdwn b/simple_v_extension.mdwn index cb2ba08fe..4cf0937ed 100644 --- a/simple_v_extension.mdwn +++ b/simple_v_extension.mdwn @@ -1,14 +1,5 @@ # Variable-width Variable-packed SIMD / Simple-V / Parallelism Extension Proposal -* TODO 23may2018: CSR-CAM-ify regfile tables -* TODO 23may2018: zero-mark predication CSR -* TODO 28may2018: sort out VSETVL: CSR length to be removed? -* TODO 09jun2018: Chennai Presentation more up-to-date -* TODO 09jun2019: elwidth only 4 values (dflt, dflt/2, 8, 16) -* TODO 09jun2019: extra register banks (future option) -* TODO 09jun2019: new Reg CSR table (incl. packed=Y/N) - - Key insight: Simple-V is intended as an abstraction layer to provide a consistent "API" to parallelisation of existing *and future* operations. *Actual* internal hardware-level parallelism is *not* required, such @@ -18,8 +9,8 @@ instruction queue (FIFO), pending execution. *Actual* parallelism, if added independently of Simple-V in the form of Out-of-order restructuring (including parallel ALU lanes) or VLIW -implementations, or SIMD, or anything else, would then benefit *if* -Simple-V was added on top. +implementations, or SIMD, or anything else, would then benefit from +the uniformity of a consistent API. [[!toc ]] @@ -695,12 +686,13 @@ permitted (as used in Broadcom's VideoCore-IV) however this must be ## Branch Instruction: -Branch operations use standard RV opcodes that are reinterpreted to be -"predicate variants" in the instance where either of the two src registers -have their corresponding CSRvectorlen[src] entry as non-zero. When this -reinterpretation is enabled the predicate target register rs3 is to be -treated as a bitfield (up to a maximum of XLEN bits corresponding to a -maximum of XLEN elements). +Branch operations use standard RV opcodes that are reinterpreted to +be "predicate variants" in the instance where either of the two src +registers are marked as vectors (isvector=1). When this reinterpretation +is enabled the "immediate" field of the branch operation is taken to be a +predication target register, rs3. The predicate target register rs3 is +to be treated as a bitfield (up to a maximum of XLEN bits corresponding +to a maximum of XLEN elements). If either of src1 or src2 are scalars (CSRvectorlen[src] == 0) the comparison goes ahead as vector-scalar or scalar-vector. Implementors should note that @@ -751,16 +743,15 @@ It is however noted that an entry "FNE" (the opposite of FEQ) is missing, and whilst in ordinary branch code this is fine because the standard RVF compare can always be followed up with an integer BEQ or a BNE (or a compressed comparison to zero or non-zero), in predication terms that -becomes more of an impact as an explicit (scalar) instruction is needed -to invert the predicate bitmask. An additional encoding funct3=011 is -therefore proposed to cater for this. +becomes more of an impact. To deal with this, SV's predication has +had "invert" added to it. [[!table data=""" 31 .. 27| 26 .. 25 |24 ... 20 | 19 15 | 14 12 | 11 .. 7 | 6 ... 0 | funct5 | fmt | rs2 | rs1 | funct3 | rd | opcode | 5 | 2 | 5 | 5 | 3 | 4 | 7 | 10100 | 00/01/11 | src2 | src1 | 010 | pred rs3 | FEQ | -10100 | 00/01/11 | src2 | src1 | **011**| pred rs3 | FNE | +10100 | 00/01/11 | src2 | src1 | **011**| pred rs3 | rsvd | 10100 | 00/01/11 | src2 | src1 | 001 | pred rs3 | FLT | 10100 | 00/01/11 | src2 | src1 | 000 | pred rs3 | FLE | """]] @@ -784,19 +775,19 @@ and temporarily ignoring bitwidth (which makes the comparisons more complex), this becomes: if I/F == INT: # integer type cmp - pred_enabled = int_pred_enabled # TODO: exception if not set! preg = int_pred_reg[rd] reg = int_regfile else: - pred_enabled = fp_pred_enabled # TODO: exception if not set! preg = fp_pred_reg[rd] reg = fp_regfile - s1 = CSRvectorlen[src1] > 1; - s2 = CSRvectorlen[src2] > 1; - for (int i=0; i + +There is no MV instruction in RV however there is a C.MV instruction. +It is used for copying integer-to-integer registers (vectorised FMV +is used for copying floating-point). + +If either the source or the destination register are marked as vectors +C.MV is reinterpreted to be a vectorised (multi-register) predicated +move operation. The actual instruction's format does not change: + +[[!table data=""" +15 12 | 11 7 | 6 2 | 1 0 | +funct4 | rd | rs | op | +4 | 5 | 5 | 2 | +C.MV | dest | src | C0 | +"""]] + +A simplified version of the pseudocode for this operation is as follows: + + function op_mv(rd, rs) # MV not VMV! +  rd = int_vec[rd].isvector ? int_vec[rd].regidx : rd; +  rs = int_vec[rs].isvector ? int_vec[rs].regidx : rs; +  ps = get_pred_val(FALSE, rs); # predication on src +  pd = get_pred_val(FALSE, rd); # ... AND on dest +  for (int i = 0, int j = 0; i < VL && j < VL;): + if (int_vec[rs].isvec) while (!(ps & 1< What does an ADD of two different-sized vectors do in simple-V? @@ -956,6 +1059,168 @@ Section "Virtual Memory Page Faults". * Throw an exception. Whether that actually results in spawning threads as part of the trap-handling remains to be seen. +# Under consideration + +From the Chennai 2018 slides the following issues were raised. +Efforts to analyse and answer these questions are below. + +* Should future extra bank be included now? +* How many Register and Predication CSRs should there be? + (and how many in RV32E) +* How many in M-Mode (for doing context-switch)? +* Should use of registers be allowed to "wrap" (x30 x31 x1 x2)? +* Can CLIP be done as a CSR (mode, like elwidth) +* SIMD saturation (etc.) also set as a mode? +* Include src1/src2 predication on Comparison Ops? + (same arrangement as C.MV, with same flexibility/power) +* 8/16-bit ops is it worthwhile adding a "start offset"? + (a bit like misaligned addressing... for registers) + or just use predication to skip start? + +## Future (extra) bank be included (made mandatory) + +The implications of expanding the *standard* register file from +32 entries per bank to 64 per bank is quite an extensive architectural +change. Also it has implications for context-switching. + +Therefore, on balance, it is not recommended and certainly should +not be made a *mandatory* requirement for the use of SV. SV's design +ethos is to be minimally-disruptive for implementors to shoe-horn +into an existing design. + +## How large should the Register and Predication CSR key-value stores be? + +This is something that definitely needs actual evaluation and for +code to be run and the results analysed. At the time of writing +(12jul2018) that is too early to tell. An approximate best-guess +however would be 16 entries. + +RV32E however is a special case, given that it is highly unlikely +(but not outside the realm of possibility) that it would be used +for performance reasons but instead for reducing instruction count. +The number of CSR entries therefore has to be considered extremely +carefully. + +## How many CSR entries in M-Mode or S-Mode (for context-switching)? + +The minimum required CSR entries would be 1 for each register-bank: +one for integer and one for floating-point. However, as shown +in the "Context Switch Example" section, for optimal efficiency +(minimal instructions in a low-latency situation) the CSRs for +the context-switch should be set up *and left alone*. + +This means that it is not really a good idea to touch the CSRs +used for context-switching in the M-Mode (or S-Mode) trap, so +if there is ever demonstrated a need for vectors then there would +need to be *at least* one more free. However just one does not make +much sense (as it one only covers scalar-vector ops) so it is more +likely that at least two extra would be needed. + +This *in addition* - in the RV32E case - if an RV32E implementation +happens also to support U/S/M modes. This would be considered quite +rare but not outside of the realm of possibility. + +Conclusion: all needs careful analysis and future work. + +## Should use of registers be allowed to "wrap" (x30 x31 x1 x2)? + +On balance it's a neat idea however it does seem to be one where the +benefits are not really clear. It would however obviate the need for +an exception to be raised if the VL runs out of registers to put +things in (gets to x31, tries a non-existent x32 and fails), however +the "fly in the ointment" is that x0 is hard-coded to "zero". The +increment therefore would need to be double-stepped to skip over x0. +Some microarchitectures could run into difficulties (SIMD-like ones +in particular) so it needs a lot more thought. + +## Can CLIP be done as a CSR (mode, like elwidth) + +RVV appears to be going this way. At the time of writing (12jun2018) +it's noted that in V2.3-Draft V0.4 RVV Chapter, RVV intends to do +clip by way of exactly this method: setting a "clip mode" in a CSR. + +No details are given however the most sensible thing to have would be +to extend the 16-bit Register CSR table to 24-bit (or 32-bit) and have +extra bits specifying the type of clipping to be carried out, on +a per-register basis. Other bits may be used for other purposes +(see SIMD saturation below) + +## SIMD saturation (etc.) also set as a mode? + +Similar to "CLIP" as an extension to the CSR key-value store, "saturate" +may also need extra details (what the saturation maximum is for example). + +## Include src1/src2 predication on Comparison Ops? + +In the C.MV (and other ops - see "C.MV Instruction"), the decision +was taken, unlike in ADD (etc.) which are 3-operand ops, to use +*both* the src *and* dest predication masks to give an extremely +powerful and flexible instruction that covers a huge number of +"traditional" vector opcodes. + +The natural question therefore to ask is: where else could this +flexibility be deployed? What about comparison operations? + +Unfortunately, C.MV is basically "regs[dest] = regs[src]" whilst +predicated comparison operations are actually a *three* operand +instruction: + + regs[pred] |= 1<< (cmp(regs[src1], regs[src2]) ? 1 : 0) + +Therefore at first glance it does not make sense to use src1 and src2 +predication masks, as it breaks the rule of 3-operand instructions +to use the *destination* predication register. + +In this case however, the destination *is* a predication register +as opposed to being a predication mask that is applied *to* the +(vectorised) operation, element-at-a-time on src1 and src2. + +Thus the question is directly inter-related to whether the modification +of the predication mask should *itself* be predicated. + +It is quite complex, in other words, and needs careful consideration. + +## 8/16-bit ops is it worthwhile adding a "start offset"? + +The idea here is to make it possible, particularly in a "Packed SIMD" +case, to be able to avoid doing unaligned Load/Store operations +by specifying that operations, instead of being carried out +element-for-element, are offset by a fixed amount *even* in 8 and 16-bit +element Packed SIMD cases. + +For example rather than take 2 32-bit registers divided into 4 8-bit +elements and have them ADDed element-for-element as follows: + + r3[0] = add r4[0], r6[0] + r3[1] = add r4[1], r6[1] + r3[2] = add r4[2], r6[2] + r3[3] = add r4[3], r6[3] + +an offset of 1 would result in four operations as follows, instead: + + r3[0] = add r4[1], r6[0] + r3[1] = add r4[2], r6[1] + r3[2] = add r4[3], r6[2] + r3[3] = add r5[0], r6[3] + +In non-packed-SIMD mode there is no benefit at all, as a vector may +be created using a different CSR that has the offset built-in. So this +leaves just the packed-SIMD case to consider. + +Two ways in which this could be implemented / emulated (without special +hardware): + +* bit-manipulation that shuffles the data along by one byte (or one word) + either prior to or as part of the operation requiring the offset. +* just use an unaligned Load/Store sequence, even if there are performance + penalties for doing so. + +The question then is whether the performance hit is worth the extra hardware +involving byte-shuffling/shifting the data by an arbitrary offset. On +balance given that there are two reasonable instruction-based options, the +hardware-offset option should be left out for the initial version of SV, +with the option to consider it in an "advanced" version of the specification. + # Impementing V on top of Simple-V With Simple-V converting the original RVV draft concept-for-concept