Marco Bodrato

I'm not sure I understand how a support/regression/tests/*.c file is supposed to work... I don't see any main function! I stole the structure from file bug-2516.c. I do not even know how much resources is reasonable to use for such a test... I attach a possible implementation.

It's maybe even more impressive to realize that dividing by 1.0 can nullify the result :-) Also the following ASSERT is currently failing: ASSERT (2.3e-38 == 0 || divTest (2.3e-38, 1.0) != 0);

Be careful! You added a bug! The following tests (I borrow the syntax from bug-2516.c) should both pass, right? Because both divisions should (approximately) return 2e-38, a non-subnormal value... ASSERT (divTest (1.4e-37, 7.0) > 1.9e-38); ASSERT (divTest (1.6e-37, 8.0) > 1.9e-38); ...but, with the new code, the second fails. I attach a patch. With it I'm also suggesting a little change to the MANT macro, to avoid resetting the 24th bit when the next operation sets it again... On the Z80 flavor,...

Well, it depend on what the test is trying to test! If one wants to verify if division by zero gives infinity instead of NaN, then one may decide to use 0.0. If one wants to verify if the division algorithm returns infinity when the result overflows, then also 1e-30 should do, shouldn't it? By the way I tried to simplify the function __fsdiv float __fsdiv (float a1, float a2) { union float_long fl; if (a2 == 0.0f) { if (a1 > 0.0f) fl.l = __INFINITY; else if (a1 < 0.0f) fl.l = SIGNBIT | __INFINITY;...

I'm not sure I understand what you are proposing. Anyway, the following code should work: mask = 0x800000; if (mant1 < mant2) mask <<= 1; else ++exp; but in that case, not only mant1, but also mask can not use a possible uint24_t...

Il 2021-03-16 11:20 Maarten Brock ha scritto: Those are some fine improvements. Would it be possible to shift mant2 right instead of shifting mant1 left at the start? No, shifting right deletes a bit. Think 2^23 / (2^23 + 1). We have 2^23 < 2^23 + 1, so the condition mant1 < mant2 is triggered. Computing (((2^23) << 1) / (2^23 + 1)) / 2 gives the same result: approximately 1 - 2^{-23}. Computing (2^23 / ((2^23 + 1) >> 1)) * 2 gives 2^23/2^22 * 2 = 1. So in effect we would have 24 bits of precision?...

Il 2021-03-16 11:20 Maarten Brock ha scritto: Those are some fine improvements. Would it be possible to shift mant2 right instead of shifting mant1 left at the start? No, shifting right deletes a bit. Think 2^23 / (2^23 + 1). We have 2^23 < 2^23 + 1, so the condition mant1 < mant2 is triggered. Computing (((2^23) << 1) / (2^23 + 1)) / 2 gives the same result: approximately 1 - 2^{-23}. Computing (2^23 / ((2^23 + 1) >> 1)) * 2 gives 2^23/2^22 * 2 = 1. So in effect we would have 24 bits of precision?...

Another possible refinement is to partially unroll a round of the loop. At the first run, the condition if (mant1 >= mant2) is always true, so that result is initialised with the bit 0x800000 set. But that bit is removed at the end by the line result &= ~HIDDEN;, and it is faster to avoid this set-reset path. Faster, but... the code is larger. For that reason I'm not proposing to adopt the attached patch, I'm sharing it here because maybe someone can improve it even more to obtain something optimal....