[libre-riscv-dev] div/mod algorithm written in python

[Jacob Lifshay]

On Sat, Jul 20, 2019 at 12:55 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> yehyeh.  well, the basic routines are all there, already done: there's
> pipeline stages already that will shift the mantissa up so that the
> MSB is always 1 (and adjust the exponent accordingly as well), and
> likewise on the way out.
>
> so as long as the integer "thing" works, fitting it in place is
> actually pretty trivial.
>
> once the result is generated, the post-normalisation pipeline stages
> take care of re-normalisation, so even if the mantissa (int-result)
> doesn't have a MSB which is 1, that's *precisely* what
> re-normalisation takes care of: shifting the MSB and adjusting the
> exponent as well.
>
> so the exponent will need to be carried through the int-div pipeline
> stages *untouched*, ok?  generated/modified by the de-normalisation,
> carried through the int-div pipe, handed to the post/re-normalisation,
> and dealt with there.
One thing we will need to consider is that sqrt/rsqrt actually
requires the mantissa to be shifted such that the exponent is even,
otherwise we lose the factor of sqrt(2). I had been thinking that,
since all normal/denormal numbers produce normal outputs for
sqrt/rsqrt (exponent divides by 2), it would be better to have the
exponent handling happen during the same stages that the mantissa is
being calculated by DivCore, since that way, we don't need an extra
stage just to handle that and it will pipeline better.

the exponent operations would be (assuming inputs and outputs are
biased and bias is positive):
fdiv: nexponent - dexponent + bias (needs overflow/underflow handling)
fsqrt: (exponent - bias) / 2 + bias (overflow/underflow impossible; no
rounding needed since (exponent - bias) is even due to extra shifting
handling sqrt(2))
frsqrt: bias - (exponent - bias) / 2 (overflow/underflow impossible;
no rounding needed -- see fsqrt case)

Jacob