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