in reply to [OT] Endianness and extended precision (80-bit) long doubles

No - this same code cannot be used.
12 or 16 bytes is normal because the total number of bytes for an integer at least needs to be divisible by 4 for efficient hardware implementation. You can access an individual byte, but the hardware can access a "row of bytes" in the same time that it can access a single byte within a row. A "row" is either 32 (4 bytes) or 64 bits (8 bytes).

I presume this for loop is within Perl code after a read of a binary file? You should consider pack() and unpack() to get the data into a Perl binary value (big endian). The right kind of pack() or unpack() is dependent upon the architecture (endianness).

It would be helpful to show some code and a short explanation of why you are accessing the individual bytes of what apparently is a multi-byte integer?
Update: too many bytes for an int.. I guess this is a float? It is quite common for binary values to written with big endian values to disk, etc.

  • Comment on Re: [OT] Endianness and extended precision (80-bit) long doubles

Replies are listed 'Best First'.
Re^2: [OT] Endianness and extended precision (80-bit) long doubles
by syphilis (Archbishop) on Aug 25, 2019 at 00:41 UTC
    It would be helpful to show some code

    Yes, it might have been clearer if I'd phrased the question in terms of pack/unpack.
    On my 64-bit little-endian machine (Ubuntu-18.04), running a perl whose NV is the extended precision (80-bit) long double, I get: 
    $ perl -le 'print unpack "h*", pack "D", sqrt 2;'
4846ed9f333f405bfff3000000000000

    [download]
    If I ran the identical one-liner on a 64-bit *big-endian* machine,running a perl whose NV is the extended precision (80-bit) long double, where would that substring of 12 consecutive zeroes appear ? Would it still appear at the end of the string (as was the case on my little-endian machine), or would it appear at the beginning ?

    I have long-standing C code in Math-MPFR (MPFR.xs) that presumes that the substring in question will appear at the end of the string, irrespective of endianess: 
    ....
  n = bits == 64 ? 10 : 16;
#ifdef MPFR_HAVE_BENDIAN /* Big Endian architecture */
  for (i = 0; i < n; i++) {
#else
  for (i = n - 1; i >= 0; i--) {
#endif
  // code that does something with byte i

    [download]
    but I don't recall having ever established the correctness of that code for the big-endian case.

    If it were incorrect, then the test suite should expose the error - but then I don't know if Math::MPFR has ever been built on a big-endian machine, using a perl whose NV is the 80-bit long double.

    Cheers,
    Rob
[reply]
[d/l]
[select]
      I am not sure that I can help. current Pack docs. I am on Perl 5.24 and it appears to me that you are using a feature from Perl 5.30? This "D" option to pack() appears in red in my browser.

      If Perl source code of: 

      $ perl -le 'print unpack "h*", pack "D", sqrt 2;'
4846ed9f333f405bfff3000000000000

      [download]
      works? I am also unsure about what will happen on a different architecture. My main machine is Intel (little endian). I have a Raspberry PI which I think is big endian, but I have a lot of hardware cables to screw around with to get it working. Sorry. 
      D  A float of long-double precision in native format.
         (Long doubles are available only if your system supports
          long double values _and_ if Perl has been compiled to
          support those.  Raises an exception otherwise.
          Note that there are different long double formats.)

h  A hex string (low nybble first).
H  A hex string (high nybble first).

      [download]
[reply]
[d/l]
[select]

        Quoth  perldoc -f pack on my 5.8.9 Perl:

        D   A long double-precision float in the native format.
            (Long doubles are available only if your system supports long
            double values _and_ if Perl has been compiled to support those.
            Causes a fatal error otherwise.)
        Also see pack. I'm not sure about the red coloration; maybe it flags a feature not supported by all word widths/compilation options. (Actually, I suspect a documentation problem since everything in the table (update: including things like  x X @ that are as old as the hills) from line 41 on is both red and italic.)

        Give a man a fish:  <%-{-{-{-<

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom