[Libre-soc-dev] setvl lost its reserved fields (was: setvl gaining CTR mode)

[Jacob Lifshay]

On Sun, Jul 3, 2022, 01:10 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Sun, Jul 3, 2022 at 7:11 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > On Sat, Jul 2, 2022, 12:01 Luke Kenneth Casson Leighton via
> Libre-soc-dev <libre-soc-dev at lists.libre-soc.org> wrote:
> > > if it wasn't for bc having a CTR-dec mode this would not be worth it.
> > > sv.bc has the abiltiy to decrement CTR in various ways, so it was
> > > quite important to also make it possible for VL to be set based on
> > > CTR.
> > >
> > > thoughts appreciated
> >
> > seems fine to me.
> >
> > though I just now noticed that at some point setvl lost the reserved bits
>
> there's up to 24 bits available from adding sv.setvl.
>

but that removes orthogonality where the sv prefix is mostly independent of
what is prefixed....imho that should be our option of last resort, since
it's also 2x as big as setvl.

>
> it's a bit late in the game to be doing full redesigns of one of
> the major fundamental instructions, when there are 100+ unit
> tests affected and we're only weeks away from the OPF ISA WG
> being ratified.
>

imho we should at least redefine the msb of SVi to be reserved as a
separate field for future extensions (lets call it `fut_mode` for now),
currently it's a constant zero. just doing this won't affect much other
than the tables defining fields and adding a new paragraph explaining how
the reserved field is explicitly reserved for future extensions that change
the register file or behavior in some other way, with an example of
extending it to 256 registers by shifting svp64 vector register fields left
by 1 bit.

one possible way to get it to work for future extensions without changing
much is for `ms` and `vs` to be repurposed only when `fut_mode = 1`
(`fut_mode` is always 0 for setvl as currently defined), leaving space to
enable multiple future extensions. that said, that cuts the space for
extensions down to 5 options rather than 8:
fut_mod=0 -- current svp64
fut_mod=1 ms=0 vs=0 -- extension mode #1 -- e.g. 256 registers
fut_mod=1 ms=0 vs=1 -- extension mode #2 -- e.g. 256 128-bit registers
fut_mod=1 ms=1 vs=0 -- extension mode #3 -- e.g. 512 128-bit registers
fut_mod=1 ms=1 vs=1 -- extension mode #4 -- e.g. 128-bit registers


> svstep. can be setvl. 0, 0, 1, vf=1 (encoded with SVi = 0)
>
> this is impossible, SVi is encoded off-by-one.


it's totally possible, that's why setvl's assembly-level immediate is 1 --
meaning SVi = 0 since the assembly-level immediate is SVi + 1. SVi is the
machine-code-level immediate.

Jacob