[Libre-soc-dev] cray-style vector of 40 years setting VL=0 at runtime
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sun Oct 2 18:51:35 BST 2022
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.
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)
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.
More information about the Libre-soc-dev