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

[lkcl]

Going back to the original topic, always a good thing.

It took me a while to realise that SVPrefix's 64 bit LD/ST.MULTI capabilities are *damaged* - impeded - by the change of VL to VLPTR.

the reason is that the hardware loops on VL (and SUBVL) have to be re-entrant as far as traps are concerned.

You do not expect the PC to increment over a batch of sequential instructions and it is no different here.

Thus, because sequential program order is preserved, one of the registers that could be overwritten by a LD.MULTI is... the very same register being pointed to *as containing VL*.

oink.

With program order being preserved it is *not* possible to say "oh that version of the register which VLPTR points to must stay the same for the whole loop", it doesn't work that way.

And if LD.MULTI is restoring the entire context of a regfile, it has to restore the reg that VL points to.

urk.

So the solution here is to allow SVPrefix to have its own independent CSR STATE, which contains all the element offsets needed for re-entrancy.

This has a nice side effect of making SVPrefix's instruction format entirely independent, with no side effects or "harm" caused to VBLOCK VL/SUBVL.

However.. what would be nice is if SVPrefix could "pick up" SUBVL/VL from VBLOCK, so for that, rather than have SVP set explicit values for SUBVL to 1,2,3,4 I am advocating they be VBLK.SUBVL,2,3,4

Likewise for P64 (which allows setting of VL, where P48 only allows setting of SUBVL) the default option is to take VBLK.VL, and to allow that to be explicitly ignored if desired.

In this way P64 can be used to explicitly target every single one of the registers x0 - x127 or it can treat them as contiguous vector-like vectors.

The new STATE CSR for SVP is only 32 bit, it is identical, and may fit cleanly into the top 32 bits on RV64.

Thoughts?

L.