[Libre-soc-dev] Vectorised mtcr and mfcr

[Richard Wilbur]

On Sat, Aug 6, 2022 at 10:29 AM lkcl via Libre-soc-dev
<libre-soc-dev at lists.libre-soc.org> wrote:
[...]
> i have not got round to putting this in the spec because there is so much else to do, but it should also be obvious to use the upper half of the CR reg to store CR8-CR15 Fields and go from there, thus making it 64 bit and therefore only needing to set VL to 8 and perform a vector sv.mfcr only of length 8.
>
> it is something of a pain to have to set VL specifically for that, which was one of the motivations in early versions of SV for embedding VL into the prefix.  we ran out of space so it was removed. i do keep wondering how to bring it back.

The elegance on context switch does make a strong argument for
embedding VL into the prefix.  One alternative concerns mtcr and mfcr.
The number of CR's is implementation-specific so could be hard-wired
into the vector version of mtcr and mfcr for a particular
implementation if the normal use case is to always dump and restore
the whole set.  Otherwise, we could encode a restricted range of VL
for mtcr and mfcr since we have only 16 registers.  Theoretically that
would only require 4 bits:  VLbitfield=0000b => scalar case (VL=1),
VLbitfield=1111b => the whole set of CR's (VL=16).  If we use your
simplifying grouping of CR's into 64-bit blocks we should be able to
get away with 3 bits:  VLbitfield=000b => (VL=1, which effectively
saves two CR's), VLbitfield=111b => (VL=8, which effectively saves all
16 CR's).