Re^3: Integer overflow

I'm trying to be less obtuse about this kind of thing; finally buckle down and learn applied bit ops and hex math and friends. Do you think you could walk (me) through exactly what's going on in this block?

  { my $q   = $result & 0xFFFF_FFFF ;
    $result = $q <= 0x7FFF_FFFF ? $q : -1 - ($q ^ 0xFFFF_FFFF) ;
  } ;
[download]

Comment on Re^3: Integer overflow Download Code

Replies are listed 'Best First'.
Re^4: Integer overflow by gone2015 (Deacon) on Apr 25, 2009 at 09:41 UTC
OK... `{ my $q = $result & 0xFFFF_FFFF ; $result = $q <= 0x7FFF_FFFF ? $q : -1 - ($q ^ 0xFFFF_FFFF) ; } ;` [download] ...the objective is to take the LS 32 bits of an integer, 32 bit or more, signed or unsigned, and set `$result` to be the signed 32 bit integer value. So: `$result & 0xFFFF_FFFF` extracts the LS 32 bits and returns an unsigned value. if the value is now `<= 0x7FFF_FFFF`, then it's positive, and we're done... ...otherwise we have `0x8000_0000..0xFFFF_FFFF` which we need to map to `-0x8000_0000..-0x0000_0001`. The XOR `$q ^ 0xFFFF_FFFF` gives `0x7FFF_FFFF..0x0000_0000`, so we complete the process by negating that and subtracting 1... or subtracting that from -1. This could also be written `-(($q ^ 0xFFFF_FFFF) + 1)`or `-((~$q + 1) & 0xFFFF_FFFF)`... which are closer to the conventional way of changing the sign -- noting that we want this to work for any size of integer from 32 up. This is assuming 2's complement signed integers. I cannot recall a sign and magnitude machine (for integers). The last 1's complement machine I worked on was a CDC6400 in the 70's. So it's a fairly safe assumption. But, you could always: `unpack('l', pack('L', $result & 0xFFFF_FFFF))`, which ensures a valid argument for `pack('L', ...)` and makes no assumptions about how `unpack('l', ...)` interprets the bits.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Integer overflow
by gone2015 (Deacon) on Apr 25, 2009 at 09:41 UTC

OK...

  { my $q   = $result & 0xFFFF_FFFF ;
    $result = $q <= 0x7FFF_FFFF ? $q : -1 - ($q ^ 0xFFFF_FFFF) ;
  } ;
[download]

$result

signed

$result & 0xFFFF_FFFF extracts the LS 32 bits and returns an unsigned value.
if the value is now <= 0x7FFF_FFFF, then it's positive, and we're done...
...otherwise we have 0x8000_0000..0xFFFF_FFFF which we need to map to -0x8000_0000..-0x0000_0001. The XOR $q ^ 0xFFFF_FFFF gives 0x7FFF_FFFF..0x0000_0000, so we complete the process by negating that and subtracting 1... or subtracting that from -1.

This could also be written -(($q ^ 0xFFFF_FFFF) + 1)or -((~$q + 1) & 0xFFFF_FFFF)... which are closer to the conventional way of changing the sign -- noting that we want this to work for any size of integer from 32 up.

This is assuming 2's complement signed integers. I cannot recall a sign and magnitude machine (for integers). The last 1's complement machine I worked on was a CDC6400 in the 70's. So it's a fairly safe assumption.

But, you could always: unpack('l', pack('L', $result & 0xFFFF_FFFF)), which ensures a valid argument for pack('L', ...) and makes no assumptions about how unpack('l', ...) interprets the bits.

[reply]
[d/l]
[select]