Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^6: Module for 128-bit integer math?

by ikegami (Pope)
on Feb 08, 2011 at 19:03 UTC ( #887031=note: print w/replies, xml ) Need Help??


in reply to Re^5: Module for 128-bit integer math?
in thread Module for 128-bit integer math?

  • Does int128() and uint128() croak for "0400000000000000000000000000000000000000"?
  • Does $x + undef and the like warn? (Note that «undef + $x» cannot warn without making «my $x; $x += int128(...)» warn.)
  • Does signed to unsigned promotion occur when required? (e.g. when adding two a large number overflows.)
  • Does unsigned to signed promotion occur when required? (e.g. when subtraction overflows to something negative.)
  • Are the string buffers always suitably aligned for a int128_t? (You use memcpy in some spots, but casts in others.)

Replies are listed 'Best First'.
Re^7: Module for 128-bit integer math?
by salva (Abbot) on Feb 09, 2011 at 11:10 UTC
    Does int128() and uint128() croak for "0400000000000000000000000000000000000000"?

    It should now ;-)

    Does $x + undef and the like warn?

    yes

    (Note that «undef + $x» cannot warn without making «my $x; $x += int128(...)» warn.)
    Operations with undefs always generate warnings. Emulating the Perl behavior for built-ins up to this level is not one of my targets.
    Does signed to unsigned promotion occur when required? (e.g. when adding two a large number overflows.)

    Does unsigned to signed promotion occur when required? (e.g. when subtraction overflows to something negative.)

    No, automatic promotions would just complicate the semantics of the module too much. Currently, the module provides modulo 2**128 signed and unsigned arithmetic and the semantics are pretty simple:

    Are the string buffers always suitably aligned for a int128_t? (You use memcpy in some spots, but casts in others.)

    Internally 128bit values are stored on the stack or on the PV slot of an SV allocated with newSV(16). As GCC seems to use 64bit instructions to load 128 bits integers from memory, alignment should be right.

      So you say that newSV(16) always allocates the bytes on a suitable memory boundary. I didn't know of any such guarantee, thus my question.

      Well, then you can replace those calls to Copy with casts and assignments

      Update: Fixed bad grammar. Also, the second paragraph should be ignored because it makes sense to support passing OOK strings to native_to_int128 functions.

        So you say that newSV(16) always allocates the bytes on a 128-bit aligned

        No, what I say is that the code generated by GCC uses 64bit operations to move data between the memory and the processor registers so a 128bits alignment is not really required.

        Any sane allocator will return memory aligned for 64bits or better. Perl custom allocator (used when set from Configure) guarantees that alignment would be suitable for doubles (so, 64bits)... or at least that's what a comment says in the place where MEM_ALIGNBYTES macro is introduced.

        update: Regarding the use of Copy, yes, it is because any string allocated outside the module can be unaligned. That includes SVs using the OOK hack and probably others.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://887031]
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: (6)
As of 2020-10-28 20:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favourite web site is:












    Results (264 votes). Check out past polls.

    Notices?