[Libre-soc-isa] [Bug 533] design new CR instructions suitable for predication

[bugzilla-daemon at libre-soc.org]

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

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|programmerjake at gmail.com    |lkcl at lkcl.net

--- Comment #4 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
got it.  i had a feeling this might be what you meant.  ok so SV doesn't have
bit-level element as a concept, appropriate as that might be for isel, setb and
so on.

from an SV perspective it falls into the category of "weird" because it needs
to be considered to be "scalar at the 32 bit CR level" i.e. treat the whole
32-bit CR as "the element" and consequently treat the int src/dest as 64-bit at
the "element" level for
scalar purposes.

             op   op   op   op   op   op   op   op
    src1:    CR0  CR1  CR2  CR3  CR4  CR5  CR6  CR7
    src2:    CR0  CR1  CR2  CR3  CR4  CR5  CR6  CR7
    dest:    i[0] i[1] i[2] i[3] i[4] i[5] i[6] i[7]

even weirder is that it will need an implicit elwidth override on ints when SV
vectorised, because strictly speaking it's a normal arithmetic op (2 CR src, 1
int dest), and normal arithmetic SV ops are treated as single-predicated and
single elwidth override.

if however it was *only* a 1-CR 1-int op then that is a standard SV
twin-predication operation, and standard SV twin predication operations should
take dual element-widths (one for src and one for dest)... argh except there's
not enough room in SV Prefix, that was part of VBLOCK, argh, argh, argh.

so we'd have to treat this one as an implicit "integer gets a default
automatic elwidth override to 8-bit" operation which, actually, is quite
reasonable if the entire operation is sort-of treated as an
8 bit operation at the scalar level.  urr :)

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