Intel library 2.0u2

Discussion around the Swiss Micros DM42 calculator.
Thomas Okken
Posts: 619
Joined: Tue May 02, 2017 3:48 pm
Contact:

Intel library 2.0u2

Post by Thomas Okken » Tue Mar 05, 2019 1:51 pm

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.
Last edited by Thomas Okken on Wed Mar 06, 2019 12:05 pm, edited 1 time in total.

Thomas_ER
Posts: 79
Joined: Mon Jul 24, 2017 1:19 pm
Location: Germany

Re: Intel library 2.0u2

Post by Thomas_ER » Wed Mar 06, 2019 10:21 am

@Thomas:
maybe David needs a direct mail.
Both visit the forum probably rarely.
[ HP48/49/50/42S/WP34/HP Prime/ DM42 (#00185+00318) ]

Thomas Okken
Posts: 619
Joined: Tue May 02, 2017 3:48 pm
Contact:

Re: Intel library 2.0u2

Post by Thomas Okken » Wed Mar 06, 2019 11:18 am

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.

grsbanks
Posts: 857
Joined: Tue Apr 25, 2017 9:23 am
Location: Preston, Lancs, UK
Contact:

Re: Intel library 2.0u2

Post by grsbanks » Wed Mar 06, 2019 12:30 pm

I put it on his radar earlier today.
Not SwissMicros staff, just an enthusiast.

ctrclckws
Posts: 13
Joined: Sun Feb 17, 2019 3:30 pm

Re: Intel library 2.0u2

Post by ctrclckws » Wed Mar 06, 2019 12:32 pm

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.

Thomas Okken
Posts: 619
Joined: Tue May 02, 2017 3:48 pm
Contact:

Re: Intel library 2.0u2

Post by Thomas Okken » Wed Mar 06, 2019 2:10 pm

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*

ctrclckws
Posts: 13
Joined: Sun Feb 17, 2019 3:30 pm

Re: Intel library 2.0u2

Post by ctrclckws » Wed Mar 06, 2019 4:59 pm

And now, after lots of thought, you know what the comment should be.

:)

User avatar
Walter
Posts: 1100
Joined: Tue May 02, 2017 9:13 am
Location: Close to FRA, Germany

Re: Intel library 2.0u2

Post by Walter » Wed Mar 06, 2019 6:46 pm

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 ;)
DM42 SN: 00041 --- Follower of Platon.

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

David
Posts: 17
Joined: Fri Apr 07, 2017 5:32 am

Re: Intel library 2.0u2

Post by David » Wed Mar 06, 2019 8:06 pm

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.

Thomas Okken
Posts: 619
Joined: Tue May 02, 2017 3:48 pm
Contact:

Re: Intel library 2.0u2

Post by Thomas Okken » Wed Mar 06, 2019 11:38 pm

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?

Post Reply