# [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.
```