Long 4Byte

[Wolfram]

Can someone tell me why this is happened?

Code: Select all

xxx.l = $FD000000
Debug Hex(xxx)

Shows FFFFFFFFFD000000

Code: Select all

xxx.l = $FD00000
Debug Hex(xxx)

Shows FD00000

Code: Select all

xxx.f = $FD00000
Debug Hex(xxx)

Shows FD000000

[Tenaja]

Can someone tell me why this is happened?

Code: Select all

xxx.l = $FD000000
Debug Hex(xxx)

Shows FFFFFFFFFD000000

Code: Select all

xxx.l = $FD00000
Debug Hex(xxx)

Shows FD00000

Code: Select all

xxx.f = $FD00000
Debug Hex(xxx)

Shows FD000000

From your results, I am presuming you are using a 64-bit os and the 64-bit compiler...right?
The reason is that in your first assignment, you are assigning a negative number. Hex() defaults to Int, so it extends the sign so the negative value (distance from zero) stays the same. If you do this, it will print your long:

Code: Select all

 xxx = $FD000000
    Debug Hex(xxx, #PB_Long)

You could also change all of the "F" values to "7" (or any smaller number) and the sign component will remain clear, and you will get what you expected.

Your second assignment does not do this because you are assigning a positive number, so no padding is required.

This is the "growing pain" of PB forcing all vars to be signed.

[Wolfram]

Can someone tell me why this is happened?

Code: Select all

xxx.l = $FD000000
Debug Hex(xxx)

Shows FFFFFFFFFD000000

Code: Select all

xxx.l = $FD00000
Debug Hex(xxx)

Shows FD00000

Code: Select all

xxx.f = $FD00000
Debug Hex(xxx)

Shows FD000000

From your results, I am presuming you are using a 64-bit os and the 64-bit compiler...right?
The reason is that in your first assignment, you are assigning a negative number. Hex() defaults to Int, so it extends the sign so the negative value (distance from zero) stays the same. If you do this, it will print your long:

Code: Select all

 xxx = $FD000000
    Debug Hex(xxx, #PB_Long)

You could also change all of the "F" values to "7" (or any smaller number) and the sign component will remain clear, and you will get what you expected.

Your second assignment does not do this because you are assigning a positive number, so no padding is required.

This is the "growing pain" of PB forcing all vars to be signed.

I'm on OSX 10.6.8 32Bit and PB 32Bit

[Tenaja]

Yeah, my bad. From the manual:

Converts a quad numeric number into a string, in hexadecimal format.
...
Type (optional) If the value should be handled as another type, one of the following value can be specified: (list of types)

So the 64-bit assumption was a mistake--all we had to do was RTFM.