[Libre-soc-isa] [Bug 1183] add /mrr mode (reverse mode) to Data-Dependent Fail-First CR_ops

[bugzilla-daemon at libre-soc.org]

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

--- Comment #3 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #2)
> (In reply to Jacob Lifshay from comment #1)
> > (In reply to Luke Kenneth Casson Leighton from bug 1044 comment #56)
> 
> > though, now that I look at it more closely, do we need SNZ that much?
> 
> yes. it provides the boolean-logic equivalent of AND OR NAND and NOR.
> i learned this trick on thinking through the design of sv.bc. have
> a look and you'll see why it's important.

ok, for fail first I can see that SNZ is intended to let you decide if the
fail-first loop stops at the first predicated-off element or not. This needs to
be clarified in the spec.
> 
> damnit i hate doing redesigns of SV this late in the game.
> 
>  |6 | 7 |19:20|21 | 22:23   |  description     |
>  |--|---|-----|---|---------|------------------|
>  |RG|SNZ|0  0 |/  | dz  sz  | simple mode                      |
>  |RG|SNZ|1  0 |/  | dz  sz  | scalar reduce mode (mapreduce) |
>  |RG|SNZ|VLI 1|inv|  CR-bit | Ffirst 3-bit mode (implicit zz=1)     |
>  |RG|SNZ|VLI 1|inv|  dz sz  | Ffirst 5-bit mode (implies CR-bit from result)
> |

imo SNZ is quite low priority for simple and mapreduce modes since all it can
do is set the output to 1, it has no effect like in fail-first. I think higher
priority is supporting zz=0 for fail-first 3-bit (where SNZ doesn't matter
anyway because we're not zeroing):

|6 | 7 |19:20|21 | 22:23   |  description     |
|--|---|-----|---|---------|------------------|
|RG|0  |0  0 |/  | dz  sz  | simple mode                      |
|RG|0  |1  0 |/  | dz  sz  | scalar reduce mode (mapreduce) |
|RG|1  |VLI 0|inv|  CR-bit | Ffirst 3-bit mode (zz=0) |
|RG|SNZ|VLI 1|inv|  CR-bit | Ffirst 3-bit mode (zz=1) |
|RG|SNZ|VLI 1|inv|  dz sz  | Ffirst 5-bit mode (implies CR-bit from result) |

Another thing I realized while working on divmod, it would be really handy if
stuff with a scalar destination would run through all elements instead of
stopping at the first, I didn't check if we do that. This is useful for not
overwriting all the CRs that you could be storing some other variable in.

e.g.:
sv.cmpi/ff=lt 0, 1, *10, 5
is:
i = 0
while i < VL:
    CR0 = cmpd(gpr[10 + i], 5)
    if CR0.lt:
        break
    i += 1
VL = i

note how only CR0 is ever written and yet the whole vector loop is run

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