The meaning of a number depends heavily on context.

&FF could mean +255 decimal; or if signed 8-bit, it could mean -127 decimal. And when you convert a negative number to a longer representation, it's important to extend the sign all the way to the left

*if it really is negative*.

We all know the rule for creating the twos-complement of a positive number: "Flip the bits and add one." But what does that really mean? Well, flipping a bit is the same as subtracting from 1. So performing the operation in 8 bits, we get

Code: Select all

```
11111111
-01100100 (=100 decimal)
---------
10011011
+00000001
---------
10011100 (=156 or -100 decimal)
```

Now mathematically, a subtraction followed by an addition is equivalent to adding the addend to the minuend before taking away the subtrahend; so we could have said

Code: Select all

```
11111111
+ 00000001
----------
100000000
- 01100100 (=100 decimal)
----------
10011100 (=156 or -100 decimal)
```

In other words, the twos-complement of an 8-bit number is equivalent to 256 minus that number. The twos-complement of a 16-bit number is equivalent to 65536 minus that number, and so forth. The extra bit gets lost (the 6502 keeps it in the Carry flag) but all is right with the bits we actually care about.

(The 6502's V flag indicates a false change of sign. This can happen if you either added a positive number to a positive number and the sum has bit 7 set, meaning it looks negative; or added a negative number to a negative number and the sum has bit 7 clear, meaning it looks positive. It indicates an overflow from the signed number space, i.e. -128 to 127.)

When you extend a number, you need to propagate the sign bit all the way to the left. So -100 in 16-bit representation would be 1111111110011100, but 156 in 16-bit representation would be 0000000010011100.

The problem is that

*you do not know for certain* whether the 32-bit number &80000000 represents the decimal number 2 147 483 648 (32-bit unsigned, or longer than 32-bit) or -2 147 483 648 (32-bit signed).

This isn't so much of problem with different lengths floating-point numbers, because they are

*always* signed, and not in a twos-complement way.

You really would need to call a function to do the sign extension from 32 to 64 bit integers, or not. Because you simply

*do not know* whether &FFFFFFFF is supposed to represent - 1 or 4 294 967 295.