On 1/22/26 02:04, Richard Henderson wrote:
On 1/22/26 09:12, Ilya Leoshkevich wrote:
+static bool float128_is_int(float128 x)
+{
+ return extract64(x.high, 0, 48) == 0 && x.low == 0;
+}
This isn't testing for integer, it's testing for 1.0eNN,
i.e. a power of two.
Whoops. Not sure what I was thinking here.
+ /* Compute precise quotient
*/ \
+ a128 = floatN ## _to_float128(a,
&env->fpu_status); \
+ b128 = floatN ## _to_float128(b,
&env->fpu_status); \
+ q128 = float128_div(a128, b128,
&env->fpu_status); \
+ \
+ /* Final or partial case?
*/ \
+ is_q128_smallish = float128_get_exp(q128) <
p; \
+ is_final = is_q128_smallish ||
float128_is_int(q128); \
The language from the manual,
# If the precise quotient is not an integer and the two
# integers closest to this precise quotient cannot both
# be represented exactly in the precision of the quotient ...
does not appear to be what you are computing here.
Certainly none of this relates to "precision of the quotient".
I was rather following the tables, I think they are more precise w.r.t.
what needs to be checked.
float128_is_int(q128) was supposed to replace the r=0 check, but it's
probably unnecessary here altogether, because if the division result is
precise, it doesn't matter which way we round. And I'm explicitly
checking for r=0 in other places.
I would imagine that all of this would be easier to accomplish if you
did this in fpu/ with FloatParts instead of continually swapping in
and out of float128.
That sounds good, I think I will also be able to reuse pick_nan and
simplify exponent manipulations then. I will give it a try.
r~
