BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

UPDATE: Never mind. Fixed it.

Why does this IC code produce different output each time given the same input? 

#! perl -slw
use Config; package F128;
use Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'END_C',  NAME => 'F128', CLEAN_AFTER_BUILD =>0, TYP
+EMAPS => './F128.typemap';
#include "../C/mytypes.h"


typedef union {
    struct {
        unsigned  sign     : 1;
        unsigned exponent :11;
        U64 mantissa :52;
    };
    double d;
    U64 u;
} DFields;

void test( double d ) {
    U32 i;
    DFields *df = (DFields*)&d;
    for( i = 0; i < 64; ++i ) printf( "%u", ( df->u & ( 1ull<<i ) ) >>
+ i ); printf( "\n" );
    printf( "%.16f mantissa:%I64u exponent:%d sign:%u\n", df->d, df->m
+antissa, df->exponent -1023, df->sign );
    return;
}


END_C
package main;

F128::test( 0.45e-10 );

[download]

typemap:

TYPEMAP
const char  * T_PV
F128        * O_OBJECT
U64           T_UV
I64           T_IV
U8            T_UV
U8          * T_PV
double        T_NV

INPUT
O_OBJECT
    if( sv_isobject($arg) && ( SvTYPE( SvRV($arg) ) == SVt_PVMG ) )
            $var = INT2PTR( $type, SvIV( (SV*)SvRV( $arg ) ) );
    else{
            warn( \"${Package}::$func_name() -- $var is not a blessed 
+SV reference\" );
            XSRETURN_UNDEF;
    }

OUTPUT

# The Perl object is blessed into 'CLASS', which should be a
# char* having the name of the package for the blessing.
O_OBJECT
        sv_setref_pv( $arg, (char *)CLASS, (void*)$var );

[download]

Results of consequestive runs:

0001010010001001000101011011101111110100101111010001001110111100
0.0000000000450000 mantissa:2403864 exponent:-875 sign:0

C:\test\mandlebrot>F128.pl
0001010010001001000101011011101111110100101111010001001110111100
0.0000000000450000 mantissa:2141720 exponent:-875 sign:0

C:\test\mandlebrot>F128.pl
0001010010001001000101011011101111110100101111010001001110111100
0.0000000000450000 mantissa:1093144 exponent:-875 sign:0

C:\test\mandlebrot>F128.pl
0001010010001001000101011011101111110100101111010001001110111100
0.0000000000450000 mantissa:2338328 exponent:-875 sign:0

[download]

The double passed doesn't change; the binary dumped via the union's U64 doesn't change; but somehow the value of the mantissa field varies?? Why gives?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Replies are listed 'Best First'.
Re: IC problem.[Solved, (feel free to reap)]
by cavac (Prior) on Jun 12, 2015 at 11:54 UTC
    You could also let us know what went wrong. That way we have a nice solution for the next user to encounter a similar problem.
    "For me, programming in Perl is like my cooking. The result may not always taste nice, but it's quick, painless and it get's food on the table."
[reply]

      This:

      typedef union {
    struct {
        unsigned sign     : 1;
        unsigned exponent :11;
        U64      mantissa :52;
    };
    double d;
    U64 u;
} DFields;

      [download]

      Should be this:

      typedef union {
    struct {
        U64 sign     : 1;
        U64 exponent :11;
        U64 mantissa :52;
    };
    double d;
    U64 u;
} DFields;

      [download]

      Turns out that unless all the bit fields are defined to be of the same unsigned type, they will not be mapped to the same unit of memory.

      I originally had them all defined as just unsigned; but the compiler complained that the mantissa was too large for a 32-bit uint. So, I switch it to U64 and it compiled.

      The problem is that produces a struct that occupies more than 64-bits. The first two bitfields are merged into a U32, but because the third is a different underlying type, it gets mapped to a different chunk of uninitialised memory. Hence, the apparently random nature of the output.

      Making all three fields the same type means they get amalgamated into a single 64-bit piece of ram. (But it took some searching to locate this rather arcane piece of knowledge.)

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
      In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
[reply]
[d/l]
[select]

        Hmm, interesting. I also would have thought that in a union-type, all variables start at offset zero.

        I thought i have seen it used something like this (pseudo-code, my C coding days are mostly over so i'm not really sure how this is all supposed to look): Image you want to have different IP records in memory, say, 

        typedef struct {
    uint32 type;
    char ip[4];
} ipv4;

typedef struct {
    uint32 type;
    char ip[16];
} ipv6;

        [download]
        Then you would be able to have an union type of both and access the first field ("type") to cast the variable to the the correct typedef?

        As said, my C coding days are mostly over. But since i have some XS work coming up, i might as well start to think about such problems right now :-)

        "For me, programming in Perl is like my cooking. The result may not always taste nice, but it's quick, painless and it get's food on the table."
[reply]
[d/l]

Back to Seekers of Perl Wisdom