[Libre-soc-dev] svp64

[Jacob Lifshay]

On Wed, Dec 16, 2020, 14:54 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Wednesday, December 16, 2020, Luke Kenneth Casson Leighton <
> lkcl at lkcl.net>
> wrote:
> > ok summary changes this afternoon:
> >
> > * made a note that the 24 bits as all zeros ahould be "SV quiescent".
>  this would allow for standard v3.1B to run "as usual" including *sigh*
> VSX.
>
> jacob
> you mentioned something about nop and how all 0s in the 24 bits "will not
> work". if that is not the case then i would like svp64 to be changed so
> that it does.  e.g. the EXTRA2/3 fields if zero mean "scalar behaviour of
> registers" and so on.
>

What I originally thought you meant is that you wanted all 0s to be an
instruction you could run to detect if SV mode is enabled and trap
otherwise, you can just use a SV prefixed
`ori r0, r0, 0` (aka nop) for that.

Note that all 0s in the suffix is specifically reserved since prefixing an
implementation-defined or illegal instruction doesn't change it's
implementation-defined/illegal state.

i cannot think of a reason at all why that would be impractical.
>
> however is there an "external" reason why it should mot work? i did not
> understand what you referenced "nop" in the chat today, can you elaborate?
>
> even if there is and there is some redundant meaning i think it wise, as i
> mentioned to Paul, that all 0s be a "switches off SV" compatibility to keep
> IBM engineers happy.
>

I would argue that having the 24 bits be all 0s to switch off SV is totally
unnecessary, we don't have to have those bits be all 0s or 1s, all we need
is the fields to be set to scalar, no elwidth override, subvl=1,
mask=always, etc. If that turns out to mean the bits are 0xDEDBEF or
0xCAFEEE or 0x123456 or 0x000000 or any other bit pattern, that doesn't
affect how it works, how it's decoded or any other relevant property. The
bits should be defined by what makes the fields easiest to decode or by
ease of understanding, not by "we need all 0s to be this special mode, who
cares how much we need to distort the fields to make that happen"
(exaggerated).

In summary, there is a scalar-only mode, but I think we don't need to force
it to be encoded as all-0s.

Note that those 24 bits are already completely taken from the range of
currently-illegal 64-bit instructions, the other 8 bits are what
differentiate it from other 64-bit instructions, so none of the 24-bit
encodings need to be reserved for non-SV purposes.

>
> yes of course VL should still be off as well (set to 1 which is the way to
> set the VL for-loop to "for i in range(1)" which is of course duh scalar).
>

You don't need to specially turn VL off, it's just ignored if all
inputs/outputs are set to scalar mode.

Jacob