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 reply 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
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 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 -


I sometimes test on an armv5te as unaligned accesses corrupt data on
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 reply "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
parent reply 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
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 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 parent reply "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
parent reply "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
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