in reply to Word reverse

As I understand the OP...

The two byte binary data sequence 45d2 (specificaly qq{\x45\xd2}) would unpack with the 'v' specifier as the hex number 0xD245. 

>perl -wMstrict -le
"my $bin = qq{\x45\xd2};
 printf qq{0x%04X \n}, unpack 'v', $bin;
"
0xD245

[download]

With the first code example of the OP, the eight byte binary data sequence 45d2ff76893a0033 (or qq{\x45\xd2\xff\x76\x89\x3a\x00\x33}) would unpack as
0xD245 0x76FF 0x3A89 0x3300. 

>perl -wMstrict -le
"my $bin = qq{\x45\xd2\xff\x76\x89\x3a\x00\x33};
 my @data = unpack 'v4', $bin;
 printf '0x%04X ', $_ for @data;
"
0xD245 0x76FF 0x3A89 0x3300

[download]

But as I understand it, amigero wants 0x76FF 0xD245 0x3300 0x3A89. 

>perl -wMstrict -le
"my $bin = qq{\x45\xd2\xff\x76\x89\x3a\x00\x33};
 my @data = map reverse(unpack 'v*'), unpack '(a4)*', $bin;
 printf '0x%04X ', $_ for @data;
"
0x76FF 0xD245 0x3300 0x3A89

[download]

It's a one-liner, but as far as 'efficiency' goes, the remarks of others are pertinent.

Replies are listed 'Best First'.
Re^2: Word reverse
by BrowserUk (Patriarch) on Oct 14, 2010 at 14:09 UTC
    As I understand the OP...

    I think you may well be right in your interpretation of what the OP has asked for.

    But the (only?) way the data could end up in that byte/word ordering, is if it is being stored as unsigned longs on a little-endian machine. In which case, it would be better to unpack it as such, and so avoid the slow, manual reordering: 

    printf "%0x\n", $_ for unpack 'V2', "\x45\xd2\xff\x76\x89\x3a\x00\x33"
+;;
76ffd245
33003a89

#or 

printf "%0x\n", $_ for unpack 'L<2', "\x45\xd2\xff\x76\x89\x3a\x00\x33
+";;
76ffd245
33003a89

    [download]

    I'm always wary of these questions when they are couched in terms of "hex" and "binary", which means different things to different people. Often either term is misused to mean ascii-fied hex data.

    In this case, the impression left by the OPs code and question are, that he is a C programmer using perl and trying to do things "the C way", and is unaware of unpack.

    Finally, depending upon what 'mode' his hex editor is in, it could be that the byte ordering of the raw data is being 'messed' with for display.

    In much the same way as od appears to 'mess' with the ordering, depending upon how you ask it to interpret the data: 

    c:\test>od -t xC src.bin
0000000 45 d2 ff 76 89 3a 00 33
0000010

c:\test>od -t x2 src.bin
0000000 d245 76ff 3a89 3300
0000010

c:\test>od -t x4 src.bin
0000000 76ffd245 33003a89
0000010

    [download]
    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.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom