[libre-riscv-dev] IEEE754 FPU

[Jacob Lifshay]

just using another 3 quotient bits for guard, round, and sticky is
incorrect. the sticky bit should be set when any of the bits past guard and
round are set. an alternative description: if the remainder non-zero, after
getting the guard and round bits, then the sticky bit is set, otherwise,
the sticky bit is zero.

The round and sticky bits basically allows you to select between these
cases:
Rounding 42.###...
00: 42 exactly
01: more than 42 but less than 42.5
10: 42.5 exactly
11: more than 42.5 but less than 43

The preceding all applies analogously to the other FP operations.

Jacob

On Sat, Feb 16, 2019, 23:48 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Sun, Feb 17, 2019 at 7:28 AM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
>
> > no need to actually do the conversion on double_adder.v at all, just
> > trust the diff and some common sense.
>
> 64-bit divide added as well: i was able to reverse-engineer the
> (uncommented) reason for the random-seeming width of the divider unit:
> it's double the internally-used mantissa length plus three bits, for
> guard / round / sticky.  so for 32-bit that's 2*24 + 3 = 51, and for
> 64-bit it's 53*2 + 3 = 109
>
> jon's code, during the normalisation phase, adds in the extra "1" into
> the mantissa (the "1" that's normally stripped off).  hmm, i should
> document that.
>
> only 3 preliminary unit tests added for each of the add64 and div64,
> we need a much more comprehensive strategy that adds literally
> hundreds of millions of unit tests.  for FP16 it may even be possible
> to consider full coverage, given how powerful modern computers are
> now.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>