[Libre-soc-dev] cray-style vector of 40 years setting VL=0 at runtime

[Luke Kenneth Casson Leighton]

On Sun, Oct 2, 2022 at 6:24 PM Jacob Lifshay via Libre-soc-dev
<libre-soc-dev at lists.libre-soc.org> wrote:

> imho it should be in SVP64, not SVP64Single, simply reuse all scalar/vector
> bits being set to scalar to mean temporarily override VL=1.

https://bugs.libre-soc.org/show_bug.cgi?id=924#c8

i don't have a problem with *all* bits being zero to indicate "reserved for
a scalar-only instruction because it's effectively a redundant encoding",
i do have a problem with having to do more detailed (costly, gate-level)
decoding.

also if predication is affected (1<<r3 in particular), that's bad.

does it work... does it work...

RT=s, RA=s, RB=s, is there anything that is "damaged", there
if VL is overridden to 1?

* elwidths - not relevant
* saturation etc - not relevant
* predication - first bit on both src and dest still applies regardless

that just leaves:

*"modes" - mapreduce, failfirst, predicate-result, and
* whether REMAP should be applied

also the important question to ask is: are there *any* circumstances
whereby you would actually want an "sv.op scalar,scalar,scalar"
within any given loop to be made a NOP by dynamic setting
VL=RA/CTR where RA/CTR=0?

also have to be thought through the implications in hardware: when
VL=0 that's all that is presently needed to tell the Issue Engine
"just skip over the sv.prefixed instruction, don't even issue it".

whereas this proposal actually requires a much more comprehensive
decode of the instruction before a decision as to whether to skip
as a NOP is permitted or not, and it involves the EXTRA2/3 bits which
are really not that easy to identify (partial decode of the Suffix)

that's a heck of a lot of questions that need answering and careful
consideration.  i like the principle, it's just making me nervous, the
cost in gate complexity.

l.