From: Luke Kenneth Casson Leighton Date: Mon, 11 Jun 2018 04:09:59 +0000 (+0100) Subject: update X-Git-Tag: convert-csv-opcode-to-binary~5228 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=4b8778990113e96ab70f6368c01a358439466253;p=libreriscv.git update --- diff --git a/simple_v_extension.mdwn b/simple_v_extension.mdwn index e05f44de6..cb2ba08fe 100644 --- a/simple_v_extension.mdwn +++ b/simple_v_extension.mdwn @@ -693,45 +693,6 @@ hardware-parallelism in the ALUs is not deployed. A hybrid is also permitted (as used in Broadcom's VideoCore-IV) however this must be *entirely* transparent to the ISA. -### Under review / discussion: remove CSR vector length, use VSETVL - -**DECISION: 11jun2018 - CSR vector length removed, VSETVL determines -length on all regs** - -So the issue is as follows: - -* CSRs are used to set the "span" of a vector (how many of the standard - register file to contiguously use) -* VSETVL in RVV works as follows: it sets the vector length (copy of which - is placed in a dest register), and if the "required" length is longer - than the *available* length, the dest reg is set to the MIN of those - two. -* **HOWEVER**... in SV, *EVERY* vector register has its own separate - length and thus there is no way (at the time that VSETVL is called) to - know what to set the vector length *to*. -* At first glance it seems that it would be perfectly fine to just limit - the vector operation to the length specified in the destination - register's CSR, at the time that each instruction is issued... - except that that cannot possibly be guaranteed to match - with the value *already loaded into the target register from VSETVL*. - -Therefore a different approach is needed. - -Possible options include: - -* Removing the CSR "Vector Length" and always using the value from - VSETVL. "VSETVL destreg, counterreg, #lenimmed" will set VL *and* - destreg equal to MIN(counterreg, lenimmed), with register-based - variant "VSETVL destreg, counterreg, lenreg" doing the same. -* Keeping the CSR "Vector Length" and having the lenreg version have - a "twist": "if lengreg is vectorised, read the length from the CSR" -* Other (TBD) - -The first option (of the ones brainstormed so far) is a lot simpler. -It does however mean that the length set in VSETVL will apply across-the-board -to all src1, src2 and dest vectorised registers until it is otherwise changed -(by another VSETVL call). This is probably desirable behaviour. - ## Branch Instruction: Branch operations use standard RV opcodes that are reinterpreted to be @@ -1988,6 +1949,45 @@ summary: don't restrict / remove. it's fine. +## Under review / discussion: remove CSR vector length, use VSETVL + +**DECISION: 11jun2018 - CSR vector length removed, VSETVL determines +length on all regs**. This section kept for historical reasons. + +So the issue is as follows: + +* CSRs are used to set the "span" of a vector (how many of the standard + register file to contiguously use) +* VSETVL in RVV works as follows: it sets the vector length (copy of which + is placed in a dest register), and if the "required" length is longer + than the *available* length, the dest reg is set to the MIN of those + two. +* **HOWEVER**... in SV, *EVERY* vector register has its own separate + length and thus there is no way (at the time that VSETVL is called) to + know what to set the vector length *to*. +* At first glance it seems that it would be perfectly fine to just limit + the vector operation to the length specified in the destination + register's CSR, at the time that each instruction is issued... + except that that cannot possibly be guaranteed to match + with the value *already loaded into the target register from VSETVL*. + +Therefore a different approach is needed. + +Possible options include: + +* Removing the CSR "Vector Length" and always using the value from + VSETVL. "VSETVL destreg, counterreg, #lenimmed" will set VL *and* + destreg equal to MIN(counterreg, lenimmed), with register-based + variant "VSETVL destreg, counterreg, lenreg" doing the same. +* Keeping the CSR "Vector Length" and having the lenreg version have + a "twist": "if lengreg is vectorised, read the length from the CSR" +* Other (TBD) + +The first option (of the ones brainstormed so far) is a lot simpler. +It does however mean that the length set in VSETVL will apply across-the-board +to all src1, src2 and dest vectorised registers until it is otherwise changed +(by another VSETVL call). This is probably desirable behaviour. + ## Implementation Paradigms TODO: assess various implementation paradigms. These are listed roughly