[Libre-soc-dev] SVP64 Vectorised add-carry => big int add

[lkcl]

On April 19, 2022 7:57:03 PM UTC, lkcl <luke.leighton at gmail.com> wrote:

>>imho having RB be able to be a vector is more important,

they're both important, so have to find a way.

>> since it
>>allows
>>using mule for vectorized 128-bit arithmetic as a pair of 64-bit
>>vectors,
>
>good point... ya know... there *is* one spare bit in the 9-bit EXTRA
>Field... :)

RA * RB + RC -> HI, LO -> RS, RT

i think it might be as simple as using the 9th bit to say whether RS is either RS=RT+VL or second mode RS=RC.

and that:

* RS=RC mode is scalar if RC is scalar, vector if RC is vector BUT
* RS=RT+VL mode takes its scalar/vector from *RT*.

the default (for Scalar Identity, where VL=1, which is when SVP64 is disabled or not implemented) would be RS=RT+VL and in Scalar Identity (all SVP64 bits zero) that would be RS=RT+1.  (exactly like for lq and stq)

the "loop" case would be when RS=RC, and RC is set to Scalar

sv.mule RA.v, RB.v, RC.s
    prod = RA*RB+RC
    RS (actually RC) = HI prod
    RT = LO prod

but there is no reason why RC should not be set Vector (and RS set to RC) which would overwrite RC as a *Vector* Accumulator which is also cool and useful.

then there is "RS=RT+VL" mode which is a way to ensure that RC is *not* overwritten, and that's useful too.

sv.mule/vc RA.v, RB.v, RC.s
    prod = RA*RB+RC
    RS (actually RT+VL) = HI prod
    RT = LO prod

so i think this covers all the possibilities and use-cases (did i miss any?) and, interestingly, does not need the trick you don't like, jacob, where RC-as-src gets a different regnum from RC-as-dest, because the RS=RT+VL mode makes it unnecessary.

l.