Intel library 2.0u2

Discussion around the SwissMicros DM42 calculator
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Intel library 2.0u2

Post 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.
Last edited by Thomas Okken on Wed Mar 06, 2019 1:05 pm, edited 1 time in total.
Thomas_ER
Posts: 192
Joined: Mon Jul 24, 2017 3:19 pm
Location: Germany

Re: Intel library 2.0u2

Post by Thomas_ER »

@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: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Intel library 2.0u2

Post by Thomas Okken »

Thomas_ER wrote:
Wed Mar 06, 2019 11: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: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Intel library 2.0u2

Post by grsbanks »

I put it on his radar earlier today.
There are only 10 kinds of people in the world: those who understand binary and those who do not.
ctrclckws
Posts: 173
Joined: Sun Feb 17, 2019 4:30 pm

Re: Intel library 2.0u2

Post 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.
DM10, DM10L: 00031 / DM11, DM11L: 00112 / DM12, DM12L: 02074
DM15, DM15L: 11069 / DM16. DM16L: 02001 / DM41, DM41L: 00859
DM41X: 00036ß / 00181 DM42: 3108 / 6084 WP43: 0032
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Intel library 2.0u2

Post 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*
ctrclckws
Posts: 173
Joined: Sun Feb 17, 2019 4:30 pm

Re: Intel library 2.0u2

Post by ctrclckws »

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

:)
DM10, DM10L: 00031 / DM11, DM11L: 00112 / DM12, DM12L: 02074
DM15, DM15L: 11069 / DM16. DM16L: 02001 / DM41, DM41L: 00859
DM41X: 00036ß / 00181 DM42: 3108 / 6084 WP43: 0032
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: Intel library 2.0u2

Post by Walter »

ctrclckws wrote:
Wed Mar 06, 2019 5:59 pm
And now, after lots of thought, you know what the comment should be.
Thus, now's the time to record it ;)
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
David
Posts: 20
Joined: Fri Apr 07, 2017 7:32 am

Re: Intel library 2.0u2

Post 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.
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Intel library 2.0u2

Post 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?
Post Reply