[Libre-soc-isa] [Bug 817] Big Integer Math (sv.adde, sv.subfe, sv.madded, 128 by 64-bit -> 64-bit div/rem, maybe more...)

[bugzilla-daemon at libre-soc.org]

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

--- Comment #40 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #39)
> just realised that another variant of madded, call it say maddd, could be
> used for high accuracy dotproduct (bug #555).
> 
> it would be:
> 
>     prod[0:127] = (RA) * (RB)
>     sum[0:127] = (RC || [0]*64) + prod
>     RT <- sum[64:127]
>     RS <- sum[0:63] # RS is either RC or RT+VL

that isn't what you want...you want the existing maddld instruction, but
extended to have rt and rc be 128-bit register pairs.
> 
> but the question is: is it worth doing in the integer space?

imho no. the existing integer maddld already returns exact results for dot
product, mod 2^64.

the only way we might want a different instruction is for 64x64->128-bit dot
product, which would be a 4-in 2-out instruction, which imho is too many regs,
otherwise we'd also be ok with bigint*word+bigint muladd which is a 4-in 2-out
op which you rejected previously.

> in FP, using 2 regs to store the intermediate result (FP128),

this has the exact same problem as bigint*word+bigint muladd which is a 4-in
2-out op...admittedly it has a better motivation than integer dot product
though.

another alternative for fp dot product with higher precision is just doing a
vector fmul followed by a tree reduction fadd, which retains most of the
precision due to values being rounded O(log N) times rather than O(N) times
from a serial reduction.

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