[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
bugzilla-daemon at libre-soc.org
Mon Apr 25 19:03:37 BST 2022
https://bugs.libre-soc.org/show_bug.cgi?id=817
--- Comment #30 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #29)
> thus even on scalar usage if un[j+n] > vn[n-1] an overflow on the 128/64
> divide will occur.
>
> any clues?
working it out (and this is for n=0):
98 k = 0; // the case of a
99 for (j = m - 1; j >= 0; j--)
100 { // single-digit
101 uint64_t dig2 = (k * b + u[j]);
102 q[j] = dig2 / v[0]; // divisor here.
103 k = dig2 % v[0]; // modulo bak into next loop
104 }
* on first entry, k=0 and v[0] must be >0 otherwise div-overflow
- therefore RA (0) < RB (v[0]) and we're good.
- and RS = modulo v[0] which is *ALWAYS*, by definition,
between 0 and v[0]-1
* on second entry therefore, k will ALWAYS be between
0 and v[0]-1
- therefore RA will ALWAYS be below RB (v[0])
so this is good, for the scalar-vector case.
but, for that qhat estimate, it goes pearshaped... with the
code as-written.
if instead however divmnu64.c calls *itself* (because the
division estimate is to be on the MSB of v) then it should
end up using k=0 lines 98-104 and all will be well
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Libre-SOC-ISA
mailing list