http://www.perlmonks.org?node_id=974336


in reply to Re^20: supporting quads on 32 bit Perl
in thread supporting quads on 32 bit Perl

I just tried 0.23 from CPAN. Math::Int64 doesn't croak when called by Test::More after a test failed anymore. Compiled without errors. I used it in my module and write a small test suite that uses Math::Int64 without any problems. I did fail a test from Math::Int64 though.
Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. C:\perl512\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_h +arness(0, 'blib\lib', 'blib\arch')" t/*.t t/as_int64.t ............ ok t/die_on_overflow.t ..... ok t/Math-Int64-Native.t ... ok t/Math-Int64.t .......... ok t/Math-UInt64-Native.t .. ok t/Math-UInt64.t ......... ok t/MSC.t ................. 1/3 # Failed test 'uint64 to NV conversion 3' # at t/MSC.t line 15. # Looks like you failed 1 test of 3. t/MSC.t ................. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests t/pods.t ................ skipped: Only the author needs to check that + POD docs are right Test Summary Report ------------------- t/MSC.t (Wstat: 256 Tests: 3 Failed: 1) Failed test: 3 Non-zero exit status: 1 Files=8, Tests=256, 1 wallclock secs ( 0.24 usr + 0.02 sys = 0.25 C +PU) Result: FAIL Failed 1/8 test programs. 1/256 subtests failed. NMAKE : fatal error U1077: 'C:\perl512\bin\perl.exe' : return code '0x +ff' Stop. C:\Documents and Settings\Owner\Desktop\cpan libs\Math-Int64-0.23> C:\Documents and Settings\Owner\Desktop\cpan libs\Math-Int64-0.23>perl + ./t/MSC.t 1..3 ok 1 - uint64 to NV conversion ok 2 - uint64 to NV conversion 2 not ok 3 - uint64 to NV conversion 3 # Failed test 'uint64 to NV conversion 3' # at ./t/MSC.t line 15. # Looks like you failed 1 test of 3. C:\Documents and Settings\Owner\Desktop\cpan libs\Math-Int64-0.23>
I'll try to update this node soon on what I think about the failed test XS wise if your not faster than me in fixing it.

edit: given this XS Func
void TwoSVs( one, two ) SV * one SV * two PPCODE: 0;
called as
my $u = string_to_uint64('0xff00_0000_0000_0000'); Dump($u); my $nv = uint64_to_number($u); Dump($nv); Local::XS::TwoSVs($u, $nv);
which showed
SV = IV(0xb04240) at 0xb04244 REFCNT = 1 FLAGS = (PADMY,ROK) RV = 0x397e8c SV = PVMG(0x8eaf6c) at 0x397e8c REFCNT = 1 FLAGS = (OBJECT,NOK,OVERLOAD,pNOK) IV = 0 NV = -5.48612406879369e+303 PV = 0 STASH = 0x8616cc "Math::UInt64" SV = NV(0x86ab0c) at 0x82bd0c REFCNT = 1 FLAGS = (PADMY,NOK,pNOK) NV = 1.83746864796716e+019
$u's &($u->sv_u.svu_rv->sv_any->xnv_u) in raw memory is
0x008EAF6C 00 00 00 00 00 00 00 ff
$nv's &($nv->sv_any->xnv_u) in raw memory is
0x0086AB0C 00 00 00 00 00 e0 ef 43
ok lets try this
my $u = string_to_uint64('0xff00_0000_0000_0000'); my $nv = uint64_to_number($u); print "nv $nv u $u \n\n";
result is
nv 1.83746864796716e+019 u 18374686479671623680
IDK how many floating point digits are supposed to be shown. VS debugger says the NV slot in the SVNV is "1.8374686479671624e+019".
(__int64 *)&(two->sv_any->xnv_u)
== 0x43efe00000000000
== 100001111101111111000000000000000000000000000000000000000000000
chop off sign bit
00001111101111111000000000000000000000000000000000000000000000
chop off exponent (11 bits)
111111000000000000000000000000000000000000000000000
== 0x7E00000000000
0x7E00000000000 2 216 615 441 596 416 unsigned __int64
IDK. I'm not a math person.
(two->sv_any->xnv_u.xnv_nv) > (2^53) true bool
my $u = string_to_uint64('0xff00_0000_0000_0000'); my $nv = uint64_to_number($u);
0xff00_0000_0000_0000 is more than 2^53, it can't be held in a NV cleanly.
0xff00000000000000 > (2^53) true bool
I don't have an infinite precision calc on hand, but 0xFF would be 64-8=56. Doubles store integers upto 2^53. There even is a Perl C const just for this, win32/config_H.vc#l4320 in perl.git.

Replies are listed 'Best First'.
Re^22: supporting quads on 32 bit Perl
by salva (Canon) on Jun 04, 2012 at 21:33 UTC
    0x43efe00000000000 is 0100001111101111111000000000000000000000000000000000000000000000 (you were missing the first 0 bit).

    Removing the sign bit and the exponent and prepending the implicit 1., results in 1.1111111000000000000000000000000000000000000000000000. So the number is 0b1.1111111 * 2** (0b10000111110 - 1023) = 0b1.1111111 * 2 ** 63 = 0xff00_0000_0000_0000. The number can be represented precisely as an NV because its last bits are zero.

    The problem seems related to the MS compiler not converting correctly between NVs and uint64.

    Could you try the current GitHub version and post here the output from MSC.t?

      I can produce for you the asm or ST register snapshots of MS VC int64 to double/NV cast if its any help. Next thing is, I'm using a DEBUGGING perl, so its compiled as -Od. VC might be doing something different conversion wise between -O1 and -Od. Then again, ikegami got the same test fail Re: supporting quads on 32 bit Perl (0.23) and he compiled probably as -O1 since thats what ActivePerl's Config.pm is set with. Got latest github. First try of MSC.t.
      C:\Documents and Settings\Owner\Desktop\cpan libs\salva-p5-Math-Int64- +f0367cb>pe rl ./t/msc.t 1..3 ok 1 - uint64 to NV conversion ok 2 - uint64 to NV conversion 2 not ok 3 - uint64 to NV conversion 3 # Failed test 'uint64 to NV conversion 3' # at ./t/msc.t line 15. Undefined subroutine &main::uint64 called at ./t/msc.t line 15. # Looks like you failed 1 test of 3. # Looks like your test exited with 255 just after 3. C:\Documents and Settings\Owner\Desktop\cpan libs\salva-p5-Math-Int64- +f0367cb>
      Fixed the missing import.
      C:\Documents and Settings\Owner\Desktop\cpan libs\salva-p5-Math-Int64- +f0367cb>pe rl ./t/msc.t 1..3 ok 1 - uint64 to NV conversion ok 2 - uint64 to NV conversion 2 not ok 3 - uint64 to NV conversion 3 # Failed test 'uint64 to NV conversion 3' # at ./t/msc.t line 15. # nv converts to uint64 as 9223372036854775808, expected: 183746864796 +71623680 # Looks like you failed 1 test of 3. C:\Documents and Settings\Owner\Desktop\cpan libs\salva-p5-Math-Int64- +f0367cb>
      Thanks for the lesson in binary math. The hex to binary converter I used, I think I highlighted wrong for the copy in in the converter, and the first 0 was chopped off. From what I read about floating points a couple days ago, exact powers of 2 floating points suffer no rounding/precision loss, and thats what you are testing here right? I might update this post soon if I discover anything interesting.

      update

      I rewrote mu64_eqn.
      SV * mu64_eqn(self, other, rev = NULL) SV *self SV *other SV *rev = NO_INIT PREINIT: uint64_t selfu64; uint64_t otheru64; CODE: selfu64 = SvU64x(self); otheru64 = SvU64(aTHX_ other); RETVAL = (selfu64 == otheru64 ? &PL_sv_yes : &PL_sv_no );
      which in C is
      XS(XS_Math__UInt64__eqn); /* prototype to pass -Wmissing-prototypes */ XS(XS_Math__UInt64__eqn) { #ifdef dVAR dVAR; dXSARGS; #else dXSARGS; #endif if (items < 2 || items > 3) croak_xs_usage(cv, "self, other, rev = NULL"); { SV * self = ST(0); SV * other = ST(1); SV * rev; uint64_t selfu64; uint64_t otheru64; SV * RETVAL; selfu64 = SvU64x(self); otheru64 = SvU64(aTHX_ other); RETVAL = (selfu64 == otheru64 ? &PL_sv_yes : &PL_sv_no ); ST(0) = RETVAL; sv_2mortal(ST(0)); } XSRETURN(1); }
      When the test fails, copied from watch window in hex and decimal
      selfu64 0xff00000000000000 unsigned __int64 otheru64 0x8000000000000000 unsigned __int64 selfu64 18374686479671623680 unsigned __int64 otheru64 9223372036854775808 unsigned __int64
      Hmmm, in SvU64
      if (SvNOK(sv)) { NV nv = SvNV(sv); if (may_die_on_overflow && ( (nv < 0) || (nv >= NV_0x1p64)) ) overflow(aTHX_ out_ +of_bounds_error_u); return nv; } 397: return nv; 100045F6 DD 45 B0 fld qword ptr [nv] 100045F9 E8 6E 04 01 00 call _ftol2 (10014A6Ch) 100045FE EB 4D jmp 1000464D
      _fto12 is a static linked piece of code in the DLL tossed in by the compiler, its not part of the CRT/not imported from the CRT DLL, its asm is
      _ftol2: 10014A6C 55 push ebp 10014A6D 8B EC mov ebp,esp 10014A6F 83 EC 20 sub esp,20h 10014A72 83 E4 F0 and esp,0FFFFFFF0h 10014A75 D9 C0 fld st(0) 10014A77 D9 54 24 18 fst dword ptr [esp+18h] 10014A7B DF 7C 24 10 fistp qword ptr [esp+10h] 10014A7F DF 6C 24 10 fild qword ptr [esp+10h] 10014A83 8B 54 24 18 mov edx,dword ptr [esp+18h] 10014A87 8B 44 24 10 mov eax,dword ptr [esp+10h] 10014A8B 85 C0 test eax,eax 10014A8D 74 3C je integer_QnaN_or_zero (10014ACBh) + arg_is_not_integer_QnaN: 10014A8F DE E9 fsubp st(1),st 10014A91 85 D2 test edx,edx 10014A93 79 1E jns positive (10014AB3h) 10014A95 D9 1C 24 fstp dword ptr [esp] 10014A98 8B 0C 24 mov ecx,dword ptr [esp] 10014A9B 81 F1 00 00 00 80 xor ecx,80000000h 10014AA1 81 C1 FF FF FF 7F add ecx,7FFFFFFFh 10014AA7 83 D0 00 adc eax,0 10014AAA 8B 54 24 14 mov edx,dword ptr [esp+14h] 10014AAE 83 D2 00 adc edx,0 10014AB1 EB 2C jmp localexit (10014ADFh) positive: 10014AB3 D9 1C 24 fstp dword ptr [esp] 10014AB6 8B 0C 24 mov ecx,dword ptr [esp] 10014AB9 81 C1 FF FF FF 7F add ecx,7FFFFFFFh 10014ABF 83 D8 00 sbb eax,0 10014AC2 8B 54 24 14 mov edx,dword ptr [esp+14h] 10014AC6 83 DA 00 sbb edx,0 10014AC9 EB 14 jmp localexit (10014ADFh) integer_QnaN_or_zero: 10014ACB 8B 54 24 14 mov edx,dword ptr [esp+14h] 10014ACF F7 C2 FF FF FF 7F test edx,7FFFFFFFh 10014AD5 75 B8 jne arg_is_not_integer_QnaN (10014A8 +Fh) 10014AD7 D9 5C 24 18 fstp dword ptr [esp+18h] 10014ADB D9 5C 24 18 fstp dword ptr [esp+18h] localexit: 10014ADF C9 leave 10014AE0 C3 ret
      Will need a while to look through this asm.

      10014A7B DF 7C 24 10 fistp qword ptr [esp+10h]
      puts 8000000000000000 in esp+10h, 0x8000000000000000 is what winds up in the uint64 in ::Int64. not 0xFF*. From x86 manual, "Integer Indefinite value (0x80000000) will be returned." from FISTP docs, "If the invalid operation exception is masked, the integer indefinite value is stored in the destination operand."

      10014A7B DF 7C 24 10 fistp qword ptr [esp+10h]
      which generated the 0x80* value, right after it executed, FPU status register was 0x3921 according to VS debugger. I don't understand LE/BE and the diagrams online of the fpu status register to decode that 0x3921.

      Update, the error is fpu invalid operation, and it has to do with the sign bit on the future int64. Given
      void NVTest() PREINIT: double d1; double d2; unsigned __int64 i64; unsigned __int64 i642; PPCODE: d1 = pow(2.0, 56.0); d1 *= 128.0; i64 = 0xFF00000000000000; _controlfp( _EM_INEXACT , _MCW_EM); i642 = (unsigned __int64)d1; d2 = (double)i64; 0;
      If d1 *= 128.0;, exception thrown/crash. If d1 *= 127.0;, then int64 0x7f00* is created, and no exception thrown. Not sure whose bug this is or how to fix it. I think its simply, fistp creates a signed int64, if the floating point higher than the max signed (0xFF00* has sign bit on for signed), exception thrown.

      Update, MSVC bug! https://connect.microsoft.com/VisualStudio/feedback/details/106531/co
        From what I read about floating points a couple days ago, exact powers of 2 floating points suffer no rounding/precision loss
        Well, not exactly. IEEE 754 double-precision floats can represent precisely any number with 53 binary digits (and that covers all the integers up to 2**53 and all the powers of two).

        It is the same as using decimal scientific notation. For instance, with a number of the form XXXeXX you can represent precisely any integer between 0 an 999, but then you can also represent precisely 5670, 56700, 567000, 5670000, etc.

        The reason of the MSC.t is that at some point, one of the errors on the compilation logs from the ActiveState build server was:

        Int64.xs(340) : error C2520: conversion from unsigned __int64 to doubl +e not implemented, use signed __int64
        There were other places where NVs where converted to uint64 and back even if the compiler didn't spot them, so I added the MSC.t tests to ensure that they were correctly handled... but the thing is that they are not! (see also this).

        Now, as a work around, I have implemented my own NV->uint64 conversion that will be used instead of the default one when the module is compiled by any MS compiler.

        Could you test the git version again?