[Libre-soc-isa] [Bug 213] SimpleV Standard writeup needed

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Mon Oct 19 06:09:55 BST 2020


https://bugs.libre-soc.org/show_bug.cgi?id=213

--- Comment #57 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
again brief message (honest), traditional vector has element data staying "in
place", it neither moves lane nor regnum (ok potentially renamed PRF ARF but no
more).

with traditional vectors typically being absolutely mentallly long to the
extent of needing external hyperfast SRAM it is both critical that they not
move about and also  the only sane way to do predicate bitmasks in this type of
arrangement is if they are treated themselves as actual vector registers.

typically (just like in RVV) which aims to do MAXVL (num of lanes) anywhere
from 1 to 2^64-1 - yes really - they take bit 0 of each element as the
predicate bit and ignore all others.

by setting a hard limit of 64 (actually len(Intreg)) we no longer have the
constraints that force predicates to be actual vectors and therefore *also no
longer need to consider them to be static in-place registers*.

the predicates in the SV arrangement i am thinking of are *input data only* and
once processed are chucked away.

this because they are stored "in-flight" and come from a Read-Hazard-protected
regfile.

the arrangement you are advocating Jacob is ideally suited to "in-place" data
processing where the expectation is that after the mask register has been
"used" y the operation it then goes on elsewhere for further processing.

what actually happens in an OoO engine is that a COPY of the Hazard-managed
register goes into a Reservation-Station latch, and after use is totally
discarded.

thus the intreg used as a predicate bitmask is COPIED

if a new predicate bitmask needs to be "generated" and it happens to involve
the current mask then ANOTHER COPY of that mask, as an intreg, will go into
ANOTHER totally separate RS latch, along with another intreg, and the result
written into an output RS latch and, after regfile DM clearance, go into
another int regfile.

operand forwarding can get that into a predicate RS without having to go into
the regfile.

these int ops (which happen by coincidence to be used as predicate masks) can
be done IN PARALLEL with the vector ops that will be using them, hilariously
using the exact same ALUs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Libre-SOC-ISA mailing list