[Libre-soc-dev] setvl encoding ideas & planning ahead for bigger register files for future processors
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon Nov 30 14:29:27 GMT 2020
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
this would give a merging of the following:
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
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
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
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.
More information about the Libre-soc-dev