[libre-riscv-dev] [isa-dev] Re: SV / RVV, marking a register as VL.

[lkcl]

On Sunday, September 1, 2019 at 5:23:14 PM UTC+1, Jacob Lifshay wrote:

came up with something, overnight:
>> https://groups.google.com/forum/#!topic/comp.arch/l2nzme2sCR0
>>
>
> 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 
error.
  

> 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 
length format.

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.

l.