Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re^20: supporting quads on 32 bit Perl

by salva (Abbot)
on Jun 04, 2012 at 14:45 UTC ( #974310=note: print w/ replies, xml ) Need Help??


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

0.23 is out.

This time I have compiled it with gcc -pedantic -std=c89 and removed all the nonstandard constructions...


Comment on Re^20: supporting quads on 32 bit Perl
Download Code
Re^21: supporting quads on 32 bit Perl
by bulk88 (Priest) on Jun 04, 2012 at 17:44 UTC
    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.
      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://974310]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (7)
As of 2014-12-26 08:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (168 votes), past polls