It's done so that addition doesn't need to have any special logic for dealing with negative numbers. Check out the article on Wikipedia.
Say you have two numbers, 2 and -1. In your "intuitive" way of representing numbers, they would be 0010
and 1001
, respectively (I'm sticking to 4 bits for size). In the two's complement way, they are 0010
and 1111
. Now, let's say I want to add them.
Two's complement addition is very simple. You add numbers normally and any carry bit at the end is discarded. So they're added as follows:
0010
+ 1111
=10001
= 0001 (discard the carry)
0001
is 1, which is the expected result of "2+(-1)".
But in your "intuitive" method, adding is more complicated:
0010
+ 1001
= 1011
Which is -3, right? Simple addition doesn't work in this case. You need to note that one of the numbers is negative and use a different algorithm if that's the case.
For this "intuitive" storage method, subtraction is a different operation than addition, requiring additional checks on the numbers before they can be added. Since you want the most basic operations (addition, subtraction, etc) to be as fast as possible, you need to store numbers in a way that lets you use the simplest algorithms possible.
Additionally, in the "intuitive" storage method, there are two zeroes:
0000 "zero"
1000 "negative zero"
Which are intuitively the same number but have two different values when stored. Every application will need to take extra steps to make sure that non-zero values are also not negative zero.
There's another bonus with storing ints this way, and that's when you need to extend the width of the register the value is being stored in. With two's complement, storing a 4-bit number in an 8-bit register is a matter of repeating its most significant bit:
0001 (one, in four bits)
00000001 (one, in eight bits)
1110 (negative two, in four bits)
11111110 (negative two, in eight bits)
It's just a matter of looking at the sign bit of the smaller word and repeating it until it pads the width of the bigger word.
With your method you would need to clear the existing bit, which is an extra operation in addition to padding:
0001 (one, in four bits)
00000001 (one, in eight bits)
1010 (negative two, in four bits)
10000010 (negative two, in eight bits)
You still need to set those extra 4 bits in both cases, but in the "intuitive" case you need to clear the 5th bit as well. It's one tiny extra step in one of the most fundamental and common operations present in every application.
There is no "128" in a signed byte. The range is
- 0 to 127 : 128 values
- -1 to -128 : 128 values
Total 256 values, ie 2^8.
Addendum based on comment (and rereading the question)
0x80
could have been considered as -128, or +128. Wikipedia explanation is worth reading
The two's complement of the minimum number in the range will not have the desired effect of negating the number.
For example, the two's complement of −128 in an 8-bit system results in the same binary number. This is because a positive value of 128 cannot be represented with an 8-bit signed binary numeral. Note that this is detected as an overflow condition since there was a carry into but not out of the most-significant bit. This can lead to unexpected bugs in that an unchecked implementation of absolute value could return a negative number in the case of the minimum negative. The abs family of integer functions in C typically has this behaviour. This is also true for Java. In this case it is for the developer to decide if there will be a check for the minimum negative value before the call of the function.
The most negative number in two's complement is sometimes called "the weird number," because it is the only exception. Although the number is an exception, it is a valid number in regular two's complement systems. All arithmetic operations work with it both as an operand and (unless there was an overflow) a result.
Furthermore, right-shifting a signed integer would have the CPU propagate the MSb (bit 7) to the right, which would be against simple logic if 0x80
is +128, as, after only one shift, we would obtain 0xC0
which is a negative number (-64)... (while a right-shift from a positive number can, normally, never produce a negative result).
Best Answer
It's not. An unsigned byte (assuming 8-bit) is from 0 to 255.
The range of a signed byte using 2's complement is from -128 to 127, directly from the definition of 2's complement:
In 8-bit, it's
10000000
, in a hypothetical 9-bit representation it's110000000
.Artificially restricting the range to -127 wouldn't achieve very much; you'd be disallowing a perfectly valid value, and generally making code more complex (what else would you do with the bit pattern
10000000
?).