www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GDC/ARM: Help needed: Porting std.math.internal.gammafunction

reply Johannes Pfau <nospam example.com> writes:
Hi,

std.math.internal.gammafunction is the last module with failing
unittest on ARM, simply because it assumes that reals are always in
x86 extended precision format which is obviously not true on ARM.

I haven't got the required (maths) knowledge to fix this, so it'd be
very appreciated if somebody could take a look.

It's actually possible to easily test this on x86 with gdc: Just install
a recent gdc build and use the -mlong-double-64 command line argument.
More details and bug report here:

https://issues.dlang.org/show_bug.cgi?id=13032
Jul 03 2014
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 03.07.2014 17:33, schrieb Johannes Pfau:
 Hi,

 std.math.internal.gammafunction is the last module with failing
 unittest on ARM, simply because it assumes that reals are always in
 x86 extended precision format which is obviously not true on ARM.

OT question: can you also check big endian behavior with your ARM system (and maybe maybe unaligned accesses) if possible - i think ARM can be configure for beeing big endian (and unaligned-unware) - or?
Jul 03 2014
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 July 2014 17:09, dennis luehring via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Am 03.07.2014 17:33, schrieb Johannes Pfau:

 Hi,

 std.math.internal.gammafunction is the last module with failing
 unittest on ARM, simply because it assumes that reals are always in
 x86 extended precision format which is obviously not true on ARM.

OT question: can you also check big endian behavior with your ARM system (and maybe maybe unaligned accesses) if possible - i think ARM can be configure for beeing big endian (and unaligned-unware) - or?

That should be possible to check - modern ARM chips are endian invariant at last check. Regards Iain
Jul 03 2014
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 03 Jul 2014 18:09:41 +0200
schrieb dennis luehring <dl.soluz gmx.net>:

 OT question:
=20
 can you also check big endian behavior with your ARM system
 (and maybe maybe unaligned accesses) if possible -

these systems. I found one or two alignment bugs in druntime, but those have been fixed. I'll probably run the next test run with http://www.mjmwired.net/kernel/Documentation/arm/mem_alignment enabled.=20
 i think ARM can be configure for beeing big endian (and=20
 unaligned-unware) - or?

ARM cores can in theory run in big endian mode but it's hard to find detailed information. From http://www.arium.com/pdf/Endianness.pdf ----------------- The ARM Architectural Reference Manual states that ARM processors are bi-endian, meaning they can operate in either little-endian or big-endian modes. The ARM processor does not have any instructions or features that affect endianness. The endianness of the system as a whole is determined by the circuitry that connects the processor to its peripheral devices. In those ARM cores that contain a System Control coprocessor (coprocessor 15), Control Register 1 contains a bit that can be used to reverse the endian configuration of the system. The overall design of the system may require that this bit be set for proper operation. Check the user=E2=80=99s manual for the board to determine the proper setting for this bit. Since this bit is cleared at reset, the software engineer still must ensure that any code that executes either directly from flash or immediately after reset is formatted for the correct endian configuration, and the reset handler code must set this bit if required. For those ARM cores that do not include coprocessor 15, the software engineer has no control over the endian configuration of the system. ----------------- So whether a SOC can actually run in big endian mode depends not only on the ARM core but also on the specific SOC. And it's often hard to find documentation for SOCs. I also don't know of any ARM big endian linux distribution.
Jul 03 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 3 July 2014 at 15:35:35 UTC, Johannes Pfau wrote:
 Hi,

 std.math.internal.gammafunction is the last module with failing
 unittest on ARM, simply because it assumes that reals are 
 always in
 x86 extended precision format which is obviously not true on 
 ARM.

 I haven't got the required (maths) knowledge to fix this, so 
 it'd be
 very appreciated if somebody could take a look.

 It's actually possible to easily test this on x86 with gdc: 
 Just install
 a recent gdc build and use the -mlong-double-64 command line 
 argument.
 More details and bug report here:

 https://issues.dlang.org/show_bug.cgi?id=13032

Warning to anyone attempting this: testing the latest gdc release, writeln and friends are broken for 64bit reals. Use core.stdc.stdio.printf with %lf instead.
Jul 03 2014
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 03 Jul 2014 16:47:41 +0000
schrieb "John Colvin" <john.loughran.colvin gmail.com>:

 testing the latest gdc release, writeln and friends are broken 
 for 64bit reals. Use core.stdc.stdio.printf with %lf instead.

Actually mixing code compiled with -mlong-double-64 and code compiled without it can't really work - so I was wrong and it's not easily possible to compile only gammafunction with -mlong-double-64 (gammefunction calls into other maths modules). So it seems to really test this, either an ARM cross compiler + ARM system could be used or druntime+phobos must be built with -mlong-double-64 as well.
Jul 03 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 3 July 2014 at 17:03:51 UTC, Johannes Pfau wrote:
 Am Thu, 03 Jul 2014 16:47:41 +0000
 schrieb "John Colvin" <john.loughran.colvin gmail.com>:

 testing the latest gdc release, writeln and friends are broken 
 for 64bit reals. Use core.stdc.stdio.printf with %lf instead.

Actually mixing code compiled with -mlong-double-64 and code compiled without it can't really work - so I was wrong and it's not easily possible to compile only gammafunction with -mlong-double-64 (gammefunction calls into other maths modules). So it seems to really test this, either an ARM cross compiler + ARM system could be used or druntime+phobos must be built with -mlong-double-64 as well.

That explains the fun situation I just hit: exp(14) == 14 whut??
Jul 03 2014
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 July 2014 18:02, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Am Thu, 03 Jul 2014 16:47:41 +0000
 schrieb "John Colvin" <john.loughran.colvin gmail.com>:

 testing the latest gdc release, writeln and friends are broken
 for 64bit reals. Use core.stdc.stdio.printf with %lf instead.

Actually mixing code compiled with -mlong-double-64 and code compiled without it can't really work - so I was wrong and it's not easily possible to compile only gammafunction with -mlong-double-64 (gammefunction calls into other maths modules). So it seems to really test this, either an ARM cross compiler + ARM system could be used or druntime+phobos must be built with -mlong-double-64 as well.

FYI, for those who don't have a ARM board at hand, there's always QEMU+chroot. http://superpiadventures.com/2012/07/development-environment/
Jul 03 2014
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 July 2014 18:27, Iain Buclaw <ibuclaw gdcproject.org> wrote:
 On 3 July 2014 18:02, Johannes Pfau via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 Am Thu, 03 Jul 2014 16:47:41 +0000
 schrieb "John Colvin" <john.loughran.colvin gmail.com>:

 testing the latest gdc release, writeln and friends are broken
 for 64bit reals. Use core.stdc.stdio.printf with %lf instead.

Actually mixing code compiled with -mlong-double-64 and code compiled without it can't really work - so I was wrong and it's not easily possible to compile only gammafunction with -mlong-double-64 (gammefunction calls into other maths modules). So it seems to really test this, either an ARM cross compiler + ARM system could be used or druntime+phobos must be built with -mlong-double-64 as well.

FYI, for those who don't have a ARM board at hand, there's always QEMU+chroot. http://superpiadventures.com/2012/07/development-environment/

Or if you're an Ubuntu user (release names are a bit outdated) https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap
Jul 03 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 3 July 2014 at 15:35:35 UTC, Johannes Pfau wrote:
 Hi,

 std.math.internal.gammafunction is the last module with failing
 unittest on ARM, simply because it assumes that reals are 
 always in
 x86 extended precision format which is obviously not true on 
 ARM.

 I haven't got the required (maths) knowledge to fix this, so 
 it'd be
 very appreciated if somebody could take a look.

 It's actually possible to easily test this on x86 with gdc: 
 Just install
 a recent gdc build and use the -mlong-double-64 command line 
 argument.
 More details and bug report here:

 https://issues.dlang.org/show_bug.cgi?id=13032

some trial and error suggests that gammaStirling needs it's threshold changing from 1024.0L to 143.0L when using 64bit reals to avoid overflow.
Jul 03 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 3 July 2014 at 17:54:17 UTC, John Colvin wrote:
 On Thursday, 3 July 2014 at 15:35:35 UTC, Johannes Pfau wrote:
 Hi,

 std.math.internal.gammafunction is the last module with failing
 unittest on ARM, simply because it assumes that reals are 
 always in
 x86 extended precision format which is obviously not true on 
 ARM.

 I haven't got the required (maths) knowledge to fix this, so 
 it'd be
 very appreciated if somebody could take a look.

 It's actually possible to easily test this on x86 with gdc: 
 Just install
 a recent gdc build and use the -mlong-double-64 command line 
 argument.
 More details and bug report here:

 https://issues.dlang.org/show_bug.cgi?id=13032

some trial and error suggests that gammaStirling needs it's threshold changing from 1024.0L to 143.0L when using 64bit reals to avoid overflow.

MAXGAMMA will also need changing. I don't think there's anything else wrong with gamma and gammaStirling, I haven't looked at the others yet.
Jul 03 2014
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 03 Jul 2014 18:13:45 +0000
schrieb "John Colvin" <john.loughran.colvin gmail.com>:

 On Thursday, 3 July 2014 at 17:54:17 UTC, John Colvin wrote:
 On Thursday, 3 July 2014 at 15:35:35 UTC, Johannes Pfau wrote:
 Hi,

 std.math.internal.gammafunction is the last module with failing
 unittest on ARM, simply because it assumes that reals are 
 always in
 x86 extended precision format which is obviously not true on 
 ARM.

 I haven't got the required (maths) knowledge to fix this, so 
 it'd be
 very appreciated if somebody could take a look.

 It's actually possible to easily test this on x86 with gdc: 
 Just install
 a recent gdc build and use the -mlong-double-64 command line 
 argument.
 More details and bug report here:

 https://issues.dlang.org/show_bug.cgi?id=13032

some trial and error suggests that gammaStirling needs it's threshold changing from 1024.0L to 143.0L when using 64bit reals to avoid overflow.

MAXGAMMA will also need changing. I don't think there's anything else wrong with gamma and gammaStirling, I haven't looked at the others yet.

Thanks for having a look at this. AFAIK this code is based on cephes, http://www.netlib.org/cephes/cprob.tgz (link to double version) so the correct values can probably be found in that source code.
Jul 03 2014