Minimum register length required to store values between -64 (hex) and 128 (hex)?

Question

What is the minimum register length in a processor required to store values between -64 (hex) and 128 (hex), assuming 2's complement format?

I was thinking an 8 bit register since a 2's complement of 8 bit register goes from 0 to 255.

Am I correct?

Answer 1

In two's complement, an 8-bit register will range from -128 to +127. To get the upper bound, you fill the lower 7 bits with 1s: 01111111 is 127 in decimal. To get the lower bound, you set the highest bit to 1 and the rest to 0: 10000000 is -128 in two's complement.

Those hex values seem a bit odd (they're powers of two in decimal), but in any case: 0x128 (the 0x is a standard prefix for hex numbers) is the larger of the numbers in magnitude, and its binary representation is 100101000. You need to be able to represent those nine bits after the sign bit. So to be able to use two's complement, you'd need at least ten bits.

Answer 2

You would not be correct even if it was 128 (Decimal) max only. Since your using 2's complement the range is actually from −(2^N−1) to +(2^N−1 − 1) where N is the number of bits. So 8 bits would have a range of −128 to 127 (Decimal).

Since you present it as actually -64 (Hex) to 128 (Hex) you are actually looking at -100 (Decimal) to 296 (Decimal). Adding a bit you increase the range up to -256 to 255 and one last addition gets you to -512 to 511. Making the necessary amount needed as 10 bits.

Now make sure that you were not dealing with -64 to 128 (Decimal). As I pointed out earlier the 8 bit range only goes to 127 which would make it a very tricky question if you were not on your toes. Then it would be 9 bits.

Answer 3

Probably you've used the wrong term. 0x64 and 0x128 are very rarely used as hex values. And if you do mean those values then obviously you can't store that big range with 8 bits. 0x128 - (-0x64) = 0x18C which needs at least 9 bits to store

OTOH 64 and 128 are extremely common values, because they're powers of 2. Using the common 2's complement encoding would also cost you 9 bits (because 128 is outside an 8-bit two's complement range) and waste a lot of unused values. But in fact there's almost no 9-bit system so you'll have to use 16-bit shorts. Hence if you want to save memory, the only way is using your own encoding.

In case that you want the value only for storage, almost any encoding is appropriate. For example, using int8_t with -64 to 127 as normal and a special case for 128 (-128, -65... any number you prefer), or an uint8_t from 0 to 192 and map the values linearly. Just convert to and from the correct value when load/store. Operations still need to be done in a type wider than 8 bits, but the on-disk size is only 8 bits

If you need the value for calculation, more care should be taken. For example you could use the excess-64 encoding in which the binary 0 represents -64, 192 represents 128, or generally a would be represented by a - 64. After each calculation you'll have to readjust the value for the correct representation. For example if A and B are stored as a and b which are A - 64 and B - 64 respectively then A + B will be done as a + b + 64 (as we've subtracted 64 one more than expected)