Page 1 of 2

Intel library 2.0u2

Posted: Tue Mar 05, 2019 1:51 pm
by Thomas Okken
The other day, I was going through the final items on the Free42 to-do list, and took another look at the Intel Decimal Floating-Point Library, update 2.0u2. This is the update that caused Y^X to freeze with integer exponents >= 2^31 on the DM42. Two things occurred to me:

1. Did you (meaning David, I assume) ever figure out why this would freeze? The Free42 Android build with 2.0u2 does not have this problem, so it doesn't appear to be an incompatibility with 32-bit ARM. My guess would be compiler bug, but that's just a guess. I haven't tried building the DM42 firmware from source and looking at the generated code.

2. According to the release notes, the only change, apart from the repeated-squaring logic in bid128_pow(), that would be relevant to Free42 is a bug fix in bid128_acos(), which fixes acos(0). That fix isn't really important to us, since Free42 works around that bug already.

It seems like the only reason to upgrade Free42 and DM42 to 2.0u2 would be if the modified bid128_pow() were more accurate and/or faster. (Less accurate would be a Bad Thing.) The release notes don't say, and I haven't tested this. Has anyone?

UPDATE: the acos bug is in acos(-1), actually, not acos(0), and the work-around in Free42 is not in core_phloat.cc as you might expect, but in in core_commands6.cc, in mappable_acos_r(), so that it can return exact results in DEG and GRAD modes. Maybe the fix should also be in core_phloat.cc, in case this bug can get hit from other code besides the real case of docmd_acos()... Hmm, I should look into that. Maybe I already did when I first coded this fix, but in that case I really should have written a comment saying so.

Re: Intel library 2.0u2

Posted: Wed Mar 06, 2019 10:21 am
by Thomas_ER
@Thomas:
maybe David needs a direct mail.
Both visit the forum probably rarely.

Re: Intel library 2.0u2

Posted: Wed Mar 06, 2019 11:18 am
by Thomas Okken
Thomas_ER wrote:
Wed Mar 06, 2019 10:21 am
@Thomas:
maybe David needs a direct mail.
Both visit the forum probably rarely.
That's OK, this is not an urgent question. I don't need a reply within 24 hours or anything. I'm just curious.

Re: Intel library 2.0u2

Posted: Wed Mar 06, 2019 12:30 pm
by grsbanks
I put it on his radar earlier today.

Re: Intel library 2.0u2

Posted: Wed Mar 06, 2019 12:32 pm
by ctrclckws
From Thomas

I really should have written a comment saying so.

From me:
Comments, the hardest part of programming. If you don't do it, it's bad. If you, but later don't understand the comment, it's worse.

Thank you for your efforts with Free42.

Re: Intel library 2.0u2

Posted: Wed Mar 06, 2019 2:10 pm
by Thomas Okken
I don't write a lot of comments, but a good rule is always: if the code does something that isn't obvious, or for reasons that aren't obvious, there should be a comment.

I the case in question, the acos bug in 2.0u1, the Free42 code is correct, but not well commented:

Code: Select all

static int mappable_acos_r(phloat x, phloat *y) {
    if (x < -1 || x > 1)
        return ERR_INVALID_DATA;
    if (x == -1)
        /* Intel library bug work-around */
        *y = flags.f.rad ? PI : flags.f.grad ? 200 : 180;
    else if (!flags.f.rad && x == 0)
        *y = flags.f.grad ? 100 : 90;
    else
        *y = rad_to_angle(acos(x));
    return ERR_NONE;
}
Where it says, "Intel library bug work-around," what's the work-around? A special case for x == -1 is needed anyway, to get an exact result in DEG and GRAD modes. The bug work-around consists of the "flags.f.rad ? PI :" part; that bit, and only that bit, would not have been necessary but for the Intel bug.

It would have been better to add if (x == -1) return PI in acos(Phloat) in core_phloat.cc, just to be safe, but the fact that I didn't turns out to be OK, because Free42 never calls that function with x == -1, because of the check in mappable_acos_r(), and because of the special case for pure-real x <= -1 in complex acosh (math_acosh() in core_math2.cc).

*phew*

Re: Intel library 2.0u2

Posted: Wed Mar 06, 2019 4:59 pm
by ctrclckws
And now, after lots of thought, you know what the comment should be.

:)

Re: Intel library 2.0u2

Posted: Wed Mar 06, 2019 6:46 pm
by Walter
ctrclckws wrote:
Wed Mar 06, 2019 4:59 pm
And now, after lots of thought, you know what the comment should be.
Thus, now's the time to record it ;)

Re: Intel library 2.0u2

Posted: Wed Mar 06, 2019 8:06 pm
by David
Thomas,

Shortly, there isn't any benefit known to me in upgrading to 2.02 version.

Now more elaborated answer.
I've thoroughly compared both 2.01 and 2.02 versions to be sure there isn't any fundamental issue in building of new library version on our (very limited) platform.
During this process I've also found that there are more changes then mentioned in release notes.
Actually I've made some fixes to Intel library (for other project) and even posted patch to Intel guys.
Anyway, nothing looked like it should impose problems to build. Still, there was something what clashed on our platform.
I don't think it is general problem which should exhibit itself on other platforms, and you definitely cannot compare big ARM CPUs along with full fledged operating systems with our tiny platform in terms what could run there.

I think the version 2.01 is proven by time to be stable, functional and not limiting (particularly because some problems are fixed directly in Free42 core). Thus, it would be only reasonable to stay with 2.01 in the future too.

Re: Intel library 2.0u2

Posted: Wed Mar 06, 2019 11:38 pm
by Thomas Okken
David, thanks for elaborating. The fixes you made to the Intel library for your other project, do you also apply them when building the DM42 firmware? If so, would Free42 benefit from these fixes as well?