On 5/20/21 8:40 AM, Peter Maydell wrote:
On Sun, 16 May 2021 at 13:38, Richard Henderson
<richard.hender...@linaro.org> wrote:
Rename to parts$N_div.
Implement float128_div with FloatParts128.
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
---
+static bool frac64_div(FloatParts64 *a, FloatParts64 *b)
+{
+ uint64_t n1, n0, r, q;
+ bool ret;
+
+ /*
+ * We want a 2*N / N-bit division to produce exactly an N-bit
+ * result, so that we do not lose any precision and so that we
+ * do not have to renormalize afterward. If A.frac < B.frac,
+ * then division would produce an (N-1)-bit result; shift A left
+ * by one to produce the an N-bit result, and return true to
+ * decrement the exponent to match.
+ *
+ * The udiv_qrnnd algorithm that we're using requires normalization,
+ * i.e. the msb of the denominator must be set, which is already true.
+ */
+ ret = a->frac < b->frac;
+ if (ret) {
+ n0 = a->frac;
+ n1 = 0;
+ } else {
+ n0 = a->frac >> 1;
+ n1 = a->frac << 63;
+ }
+ q = udiv_qrnnd(&r, n0, n1, b->frac);
Hi -- Coverity is suspicious about this line (CID 1453209),
because udiv_qrrnd()'s prototype is
static inline uint64_t udiv_qrnnd(uint64_t *r, uint64_t n1,
uint64_t n0, uint64_t d)
but here we pass n0, n1 rather than n1, n0...
Bug, or false positive ?
I think it's a false positive.
Different naming schemes between gcc (from whence qrrnd came, 0 as least
significant element) and the Berkeley softfloat code (0 as most significant
element).
r~
