Signed integers

0111 1111 1111 1111      -32767
0111 1111 1111 1110      -32766

0111 1111 1111 1110        32766
0111 1111 1111 1111        32767

Does it make sense to you that pattern 0111 1111 1111 1111 is BOTH -32767 AND 32767?

How can that be?

16-bit 2's complement signed integers

1000 0000 0000 0000   -32,768
1000 0000 0000 0001   -32,767
...
1111 1111 1111 1110   -    2
1111 1111 1111 1111   -    1
0000 0000 0000 0000        0
0000 0000 0000 0001   +    1
0000 0000 0000 0010   +    2
...
0111 1111 1111 1110   +32766
0111 1111 1111 1111   +32767

 

Read the reference I posted above. The hardware you are using likely considers integers to be 32 or 64 bits, which can contain much larger values.

The integer datatype (in C) is hardware -- not compiler -- dependent.

The integer datatype in C is most definitely compiler-defined. The definition used by the compiler often reflects the capabilities of the hardware being targeted, but it is defined by the compiler. This HAS to be this way, otherwise code that was compiled on a 16-bit platform would suddenly behave very differently if run on a 32-bit or 64-bit platform.

If you install a 32-bit compiler on a 64-bit machine, the code it produces is 32-bit code regardless of the fact that the hardware is 64-bit and that the natural width of an int would ideally be 64 bits. The width of the int in programs compiled by that compiler will be 32-bits.

 

Does it make sense to you that pattern 0111 1111 1111 1111 is BOTH -32767 AND 32767?

Sorry It was my mistake. It was mistakenly typed.

What do you think about my example. Do you see any another mistake?

 

Sorry It was my mistake. It was mistakenly typed.

What do you think about my example. Do you see any another mistake?

Uh, yeah... lot's of mistakes. I'm not going to guess which are and which aren't sloppy typing errors. You need to pay more attention to detail.

Why do you claim that -32,768 requires 17 bits? It doesn't -- at least not as a 2's complement value.

 

The integer datatype in C is most definitely compiler-defined. The definition used by the compiler often reflects the capabilities of the hardware being targeted, but it is defined by the compiler. This HAS to be this way, otherwise code that was compiled on a 16-bit platform would suddenly behave very differently if run on a 32-bit or 64-bit platform.

If you install a 32-bit compiler on a 64-bit machine, the code it produces is 32-bit code regardless of the fact that the hardware is 64-bit and that the natural width of an int would ideally be 64 bits. The width of the int in programs compiled by that compiler will be 32-bits.

Of course you are correct.

I wasn't clear in that all definitions are pretty much compiler defined -- and some of those definitions are chosen to reflect the nature of the underlying target hardware.

 

Of course you are correct.

I wasn't clear in that all definitions are pretty much compiler defined -- and some of those definitions are chosen to reflect the nature underlying target hardware.

That's a good way of expressing it.

 

The root problem in this discussion is the ambiguity associated with a string of bits. The bits don't care how we interpret them, they're just bits after all. It is our "directions" to the compiler. E.g. Treat this string of bits named "n" as an unsigned integer. This direction to the compiler, also known as, declaring the type of a variable tells the compiler what it needs to know to do comparisons and to interpret results. If we say instead, treat this other string of bits named "s" as a signed integer, then again the compiler knows what to do.

Why is this important? The two stings of bits could be equal as strings of bits and be unequal as signed integers.

 

Uh, yeah... lot's of mistakes. I'm not going to guess which are and which aren't sloppy typing errors. You need to pay more attention to detail.

Why do you claim that -32,768 requires 17 bits? It doesn't -- at least not as a 2's complement value.

My mistake
Negative positive signed number for 4 bit registers.

1000   -   8
1001   -   7
1010   -   6
1011   -   5
1100   -   4
1101   -   3
1110   -   2
1111   -   1
0000       0
0001   +   1
0010   +   2
0011   +   3
0100   +   4
0101   +   5
0110   +   6
0111   +   7

So I can make this type of table for 8 bit ,16 bit, 32 bit and 64 bits

 

My mistake
Negative positive signed number for 4 bit registers.

1000   -   8
1001   -   7
1010   -   6
1011   -   5
1100   -   4
1101   -   3
1110   -   2
1111   -   1
0000       0
0001   +   1
0010   +   2
0011   +   3
0100   +   4
0101   +   5
0110   +   6
0111   +   7

So I can make this type of table for 8 bit ,16 bit, 32 bit and 64 bits

Absolutely! Knock yourself out!

 

You can make a table for anything you want.

1000 - 123
1001 - 45678
1010 - NORTH
1011 - GREEN
1100 - SOFT
1101 - COLD
1110 - 9999
1111 - YELLOW
0000 - OFF
0001 - SOUTH
0010 - RED
0011 - HOT
0100 -MEDIUM
0101 - BLACK
0110 - 34
0111 - HARD

It is just coded information. Just as long as you know that the code means.

 

Don't make it complicated. 8 bits is 8 bits. Telling the compiler that your int is signed or unsigned only changes how the code interprets the MSB (most significant bit). For an unsigned int the MSB is just part of the number. For a signed int the MSB is the sign bit, 0=positive, 1=negative. So with a signed int you actually only have 7 bits for the value, and the 8th bit is for the sign. With 7 bits you can only count to 127. For unsigned all 8 bits are used for value, and you can count to 255 with 8 bits. Write the numbers out in binary and it will be obvious.

 

Windows calculator in Programmer mode is a handy tool to see how all of this works. Just punch in a number and see what the 2's complement bits are on the data size you want. You can count by punching in the starting number then add 1. Each time you hit '=' it will count by one. Start at 32760 add 1 and count up to see what happens when you go past 32767.

 

Don't make it complicated. 8 bits is 8 bits. Telling the compiler that your int is signed or unsigned only changes how the code interprets the MSB (most significant bit). For an unsigned int the MSB is just part of the number. For a signed int the MSB is the sign bit, 0=positive, 1=negative. So with a signed int you actually only have 7 bits for the value, and the 8th bit is for the sign. With 7 bits you can only count to 127. For unsigned all 8 bits are used for value, and you can count to 255 with 8 bits. Write the numbers out in binary and it will be obvious.

It's not that simple. The MSB of a signed integer is NOT just 0 = positive and 1 = negative. If that were the case, then the representation for -1 in an 8-bit representation would be 10000001 instead of it nearly always being 11111111. Nearly all signed integer representations use two's complement in which the weight of the msb is -(2^N) where N is the number of bits.

 

I believe you are correct, thank you for catching my error. If I'm not mistaken (again) the MSB will give you the sign, and if the MSB is 1 then the number is negative and stored as 2's complement, on most platforms. I guess technically positive and negative numbers are stored as 2s complement.