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

[Luke Kenneth Casson Leighton]

On Mon, Nov 30, 2020 at 11:40 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> I thought of something: what if we required MVL to be limited to a few
> special values: 0, 1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 16, 24, 32, 48, 64?

hmmm.... i like the logic.  however if going down this route my
feeling is that it should cover the following:

elwidth=default (64) 0-7
elwidth=32 0-7
elwidth=16 0-7
elwidth=8 0-7

this would give a merging of the following:

0,1,2,3,4,5,6,7
0,2,4,6,8,10,12,14
0,4,8,12,16,20,24,28
0,8,16,24,32,40,48,56

which would take more than 4 bits to encode

the reasoning being that to do a high-performance 8-bit "thing" it
would be encoded as MVL=8/16/24/32/40/48/56/64 and if some of those
aren't part of the MVL set then the purpose of SV is somewhat
compromised.

likewise a high-performance 16-bit vector-sequence would be done, i
would expect, as MVL=16/32/48/64

only when you get to 64 bit is it reasonable to set MVL=1/2/3/4/5/6/7/8

now, if it so happens that some of those 8/16-elwidth scenarios can be
reached with SUBVL=2/3/4 - without penalising predication - then i'm
happy for MVL to be limited to a subset.

on the *other* hand given that in SV-P48 the range of registers that
can be reached is multiples of 2, it makes no sense to have MVL be odd
numbers anyway... under the *SV-P48* context, that is.

and on the other hand, this was precisely why SV-P64 was designed to
extend the bits of the register numbering to the full 7 bits.

thus i would argue that either:

a) the concept of subsetting MVL would only make sense 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.

b) therefore i conclude that you must be talking about a hypothetical
(as yet undocumented) alternative variant of SV-P64 (abandoning the
current SV-P48 and P64) where there exists huge pressure on the
available bit encoding space (i recall you mentioned that there is
only 24 bits for *everything* when trying to use v3.1B 64-bit
prefixing).

under circumstance (b), given that the reasoning behind why you're
advocating this reduced subset, i infer that there is additional
pressure not yet discussed, i'd very much prefer to see the full
trade-offs, properly outlined in full, documented, and properly
discussed, rather than there be a "small window" on a larger design.
which... as i warned about... will take a long time (several weeks if
not months).

given the complexity and implications if we get this analysis wrong is
precisely why i do not want to go down the route of re-designing
SV-P48 and SV-P64.

basically: every time that "pressure" results in a limited subset of
potential functionality, the implications - which could be
far-reaching and detrimental - need a *full* discussion.

l.