[Libre-soc-dev] setvl encoding ideas & planning ahead for bigger register files for future processors

[Jacob Lifshay]

On Mon, Nov 30, 2020, 06:30 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> a) the concept of subsetting MVL would only make sense


subsetting MVL makes sense because, practically speaking, most code will
only use a few lengths and will not be using every weird possible MVL
value. e.g. fragment shaders will always have VL be a multiple of 4 (since
pixels are in groups of 4 to compute screen-space derivatives needed for
texturing), so having a MVL that is not a multiple of 4 just wastes
registers. Likewise, most video codecs operate on 8x8 or larger 2D blocks
for discrete cosine transform, so MVL will likely be some multiple of 8.

That said, subsetting MVL is not really the important part of the proposal
-- I will readily discard subsetting MVL. The important part is reserving
2-3 bits for encoding future register file expansion and trapping when
those bits are not a supported value (just 0 for now).

when applied to
> SV-P48, and only if there happened to be circumstances where it was
> inappropriate to use up a lot of the 32-bit v3.0B encoding space for
> the 12 or so bits to encode both MVL and VL in the same instructions.
> given that no such pressure exists on the 32-bit space, there is
> correspondingly no pressure/justification to use a subset of MVL when
> using a 32-bit v3.0B encoding for the "setvl" / "setmvl" instruction.
>

I was thinking there might be pressure considering that for setvli we don't
want to use an entire primary opcode just on setvli. The new part I am
proposing is not as much that we should reencode VL/MVL immediates to use
less bits, but more that we should explicitly reserve 2/3 bits in the
setvl/setvli instructions to encode that code is using the future modes
that have more than 128 int (or fp) total registers and trap if those bits
are not zero in the current implementation to allow emulation.

approximate 32-bit encoding:
(sorry for bad spacing, I'm not using a fixed-width font)

          setvl          setvli
PO     TBD           TBD
RT       RT             RT
RS/VL  RS            VL (immediate)
XO        TBD         TBD
Future  reserved   reserved
MVL     MVL        MVL

MVL is always an immediate, since the backing registers for vectors are
always allocated at compile-time and sizes are known ahead of time.
Future is 2-3 bits, current processors *must trap* if non-zero.

Now that I think of it, setvli can share VL and MVL fields because
practically speaking they will always be identical, so there is waay less
pressure than originally anticipated. I guess we could then share encodings
by having RS=0 mean setvli and RS!=0 mean setvl.

new approximate 32-bit encoding:

          setvl          setvli
PO     TBD           TBD
RT       RT             RT
RS       RS            0
XO        TBD         TBD
Future  reserved   reserved
MVL     MVL        MVL/VL


> b) therefore i conclude that you must be talking about a hypothetical
> (as yet undocumented) alternative variant of SV-P64


Nope.

Jacob