[libre-riscv-dev] [isa-dev] Re: SV / RVV, marking a register as VL.
luke.leighton at gmail.com
Sun Sep 1 18:35:27 BST 2019
On Sunday, September 1, 2019 at 5:23:14 PM UTC+1, Jacob Lifshay wrote:
came up with something, overnight:
> Few comments:
> the SVPMode table needs to have all entries use different encodings (they
> all currently encode to 0b00)
good catch - they're in the commentary below, but not the table. cut/paste
> The encodings don't match the RISC-V long-instruction encodings (SVPMode
> would need to be moved to accommodate the 1s and 0 needed to produce 48,
> 64, 80, 96, and larger bit lengths).
ah. right. the 80+-bit format works slightly differently. from Section
1.5 of the RV spec, bits 12-14 specify the length according to the formula
"80 + NNN * 16", for all values of NNN != 0b111. when bits 12-14 are all
set to 0b111, that indicates *another* encoding, the 192-and-above bit
despite these being moot (as in: they're not *actually* 80+-bit or 192+-bit
opcodes), i really like the longer-formats. but that's off-topic.
it's moot because actually the opcode header/identifier is purely used to
put the processor into "Vector Context Mode". it is *NOT* required to have
a massive buffer in which to store the entire 80+ or 192+ bit opcode.
Program Order is *still maintained*, EVEN THOUGH a new "context" (Vector
Block Context) has been "activated".
branches and jumps are prohibited within the VBLOCK because the PC has been
"frozen" i.e. it still points to the *START* of the VBLOCK.
it is bits 0-4 of PCVBLK (Program Counter for VBLOCK) that get incremented,
*NOT* the Program Counter.
this is why i said (in an earlier message) in SV that there are nested
hardware for-loops: PC, PCVBLK, VL and SUBVL.
* PC incrementing is paused whilst PCVBLK is in effect
* PCBVLK incrementing is paused whilst VL is in effect
* VL incrementing is paused whilst SUBVL is in effect.
More information about the libre-riscv-dev