Does this look right for the value in your example?

$n = unpack 'N', pack 'B32', '01000010001111000000000000000000';;

( $s, $c, $e ) = ( 
    $n & 0x8000_0000, 
    (( $n >> 24 ) & 0x7f) - 64, 
    (($n & 0x00ffffff) / 0xffffff) * 16 
);;

print $s, $c, $e;;
0 2 3.75000022351743

$num = ($s? -1 : 1 ) * $e * 10**$c;;

print $num;;
[download]

375.000022351743

If so, then the following modification of your subroutine may be what you need:

sub parse_E ($) {
    my $data = shift; ## The data comes in as a 4-byte string so...
    $data = unpack 'N', $data; ## We need to treat it as an unsigned i
+nteger
    ## in order to do bitwise math on it

    my ($sign, $characteristic, $fraction);
    $sign = ($data & 0x80000000) ? -1 : 1;
    $characteristic = (($data >> 24) & 0x7f) - 64;
    $fraction = (($data & 0x00ffffff) / 0xffffff) * 16;

## Not the fraction raised to the power of the characteristic
##    my $num = $sign * $fraction ** $characteristic;  

## But rather, the fraction * 10 to the power of the characteristic
    my $num = $sign * $fraction * 10 ** $characteristic; 

    printf("DEBUG: parse_E(%32s)\n\tsign: %d charisteristic: %d ".
        "fraction: %f = %f\n",
        unpack ("B32", $data), $sign, $characteristic, 
        $fraction, $num);
    printf("DEBUG: unpacked characteristic  %s\n", 
       unpack ("B7", ($data >> 24) & 0x7f));
    printf("DEBUG: unpacked fraction        %7s%s\n", " ",
       unpack ("B24",  $data & 0x00ffffff));

    return $num;
}
[download]

Some inferences drawn from here, though it could definitely be more clearly stated.

Yah, that looks right. It didn't occur to me to unpack something I've already unpacked. I ended up grabbing substr's of an unpacked bitstring of my original data, in a rather ugly form.

And yes, I also had to correct my math. I'll change it back to (presumably more effecient) bit fiddling tomorrow. For now, here's what I've ended up with:

sub parse_E ($) {
    my $data = shift;

    my $databs = unpack ("B32", $data);
    
    my $sign           = oct ("0b" . substr ($databs, 0, 1)) ? -1 : 1;
    my $characteristic  = oct ("0b" . substr ($databs, 1, 7)) - 64;
    my $exponent    = 16 ** $characteristic;
    my $fraction      = oct ("0b" . substr ($databs, 8, 24)) / 0xfffff
+f; 
    my $num     = $sign * $fraction * $exponent;

    return $num;
}
[download]

Thanks much!

-- Pat

I don't know why you're dividing the fraction part by 0xFF_FFFF, if you want to do it that way you'd surely want to divide by 0x100_0000.

The following:

my $f = unpack('N',  pack('B32', "01000010001111000000000000000000")) 
+;

printf "0x%08X = %12.9f\n", $f, conv_HFP($f) ;

sub conv_HFP {
  my ($f) = @_ ;

  my $s = ($f & 0x8000_0000) ? -1 : +1 ;
  my $e = (((($f >> 24) & 0x7F) - 0x40) * 4) - 24 ;

  return $s * ($f & 0xFF_FFFF) * (2 ** $e) ;
} ;
[download]

will convert 4 byte 360/370 style radix 16 floats (where b31 is sign, b30..b24 is exponent biased by 0x40, and b23..0 is the fraction with binary point to the left of b23). Using the one example I can see the result is:

  0x423C0000 = 60.000000000

From a quick poke around, it appears that floats are stored big-endian.

I note that you say these are "IBM 390 E format 4 byte floats". The ESA/390 supports both the old 360/370 HFP (hex floating point) and new newer BFP (binary floating point) which conforms to IEEE 754-1985. Converting BFP can be done so:

my $f = unpack('N',  pack('B32', "01000010001111000000000000000000")) 
+;

printf "0x%08X = %12.9f\n", $f, conv_BFP($f) ;

sub conv_BFP {
  my ($f) = @_ ;

  my $s = ($f & 0x8000_0000) ? -1 : +1 ;
  my $e = ((($f >> 23) & 0xFF) - 0x7F) - 23 ;

  return $s * (($f & 0x7F_FFFF) | 0x80_0000) * (2 ** $e) ;
} ;
[download]

in the unlikely event your native floating point is not IEEE 754-1985 !! (Otherwise unpack('f', ...), with suitable care over the byte ordering !)

which indicates that I don't know what the floop unpack("a4") does.

substr($_, 0, 4)
[download]

substr(do { _utf8_off(my $internal = $_); $internal }, 0, 4)
[download]

Or rather

substr 
    substr(do { _utf8_off(my $internal = $_); $internal }, 0, 4) 
    . chr(0) x 4, 0, 4;
[download]

How's that! (for out-pedanting the pedant! (Always assuming I got it right :)

From perlfunc:pack (I'm too tired to fix up the link):

a A string with arbitrary binary data, will be null padded.

---

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".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

That's wrong.

While pack (whose documentation you quoted) will add NULs, unpack doesn't.

>perl -le"print length unpack 'a4', ''"
0
[download]

If anything, unpack should do the opposite (remove trailing NULs), but it doesn't do that either.

>perl -le"print length unpack 'a4', qq{\0\0\0\0}"
4
[download]

2)If you want to read binary data, open a file in binmode... local $/ = undef; is not needed.

3)Once you are dealing with binary data, study page 758 of "Programming Perl, 3rd edition" very carefully. One thing to be aware of is for example: "big-endian" vs "little-endian" order. Some machines put the most significant 16 bits first of 32 bits and some put it vice-versa. IBM has many machines and some do it one way and some another.

In your situation, look at nN and vV and the other options.

Perl can do binary editing quite well.

I offer one of the very first Perl subs that I wrote. This is from more than a decade ago. I would do some things differently now. But this does slam multiple Windows .wav files of the same type together into a new .wav file. This is just a simple example of binary editing.

I am not at all sure that STDIN can even be opened in binary mode at all!

Yes it works the same on STDIN as other handles. Specifically, it disables crlf→lf conversion on Windows machines, it stops treating chr(26) as the end of file on non-PerlIO Windows builds, and does nothing elsewhere.

I mean CTL-C, CTL-Z mean things to STDIN although these are certainly valid binary values.

No they don't. They may mean something to the tty/console, but STDIN doesn't even know about the Ctrl key. It doesn't treat character 3 or 26 specially.

>perl -e"print qq{\x03\x1A}" | perl -le"print uc unpack 'H*', <STDIN>"
031A

$perl -e'print qq{\x03\x1A}' | perl -le'print uc unpack "H*", <STDIN>'
031A
[download]

If you want to read binary data, open a file in binmode... local $/ = undef; is not needed.

Not true at all. $/ is quite useful on binary files.

my @records = map parse_rec($_),
              map /(.{$RECSIZE})/sg,
              do { local $/; <$fh> };
[download]

and

my @records;
local $/ = \$RECSIZE;
local *_;
while (<$fh>) {
   push @records, parse_rec($_);
}
[download]

are equivalent to

my @records;
local *_;
while (read($fh, $_, $RECSIZE)) {
   push @records, parse_rec($rec);
}
[download]

Mind you, read is unaffected by $/, but that has nothing to do with whether the file is binary or not.

I use STDIN for command line filters of "catable files" (text), eg. cat or "type" in the Windows world can display those files. I stand corrected about use of a binary file for such a purpose.

I am curious as to what "*_" means? I couldn't find that in my reference books.

The kind of binary files I usually deal with might have an odd number of bytes and I have to fix it up in the final result with either 16 bit aligned or 32 bit aligned values. Sometimes that means shifting things over a byte or more, So something like:
my $n_bytes = read(INBIN, $buff, $BUFSIZE); is the ticket. Your mileage may vary as they say! I haven't written any really hairy binary stuff in Perl.

I don't see any mention of floating point value conversion in the POD?

---

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".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Oops my bad!