How are Signed integers different from unsigned integers once compiled

Question

How are Signed integers different from unsigned integers once compiled?

I already know about twos compliment and the like but my question is how can you tell the difference when looking at 8 bit integers when in binary eg 10000001 if this is a signed integer it would be equal to -127 but if it is unsigned it would be equal to 129. So my question is how can you tell the difference when presented with just 8 binary bits.

And also how are signed integers different from a compilers perspective, and how can a CPU tell the difference while performing arithmetic on them

Answer 1

For simple types, you can't tell by looking at the bits in memory. Because the source specifies that the data is of a particular type, the compiler generates code that interprets the bits in memory as representing data of that particular type. In particular, in cases where different CPU instructions are needed (e.g., integer vs floating point), the compiler will generate instructions appropriate for the datatype in question. Note that, by the magic of two's complement, signed and unsigned integers are added, subtracted and multiplied by the same instructions. (That is, if you compute $z=x\times y$ believing that $x$ and $y$ are unsigned and I then tell you that they're actually signed, all you need to do is interpret $z$ as being signed and you have the right answer.)

Depending on the language, objects may or may not have some sort of tag that says what class the object instantiates. But the same considerations as above apply: there's no physical difference in memory between the tag and any other datatype that happens to have the same number of bits.

Answer 2

There is no way to tell if 8 bits in memory are a signed integer, an unsigned integer, a character, or part of a bigger data. The knowledge is put in the instructions.

As stated by David Richerby, two's complement makes signedness transparent in most operations (addition, substraction, multiplication), but some are different: the bitwise shift may preserve or ignore the sign bit. Some processors implement arithmetic shift to preserve sign bit (acting like a division, even on negative numbers) and logic shift (which is suitable for unsigned integers). When you compile your source code, the compiler knows the type of your data, and generate the program with the instruction that fit with your use-case.

Please note that some processors implement only one type of bit shifts. In such case, to keep the same behavior, the compiler will add some extra instructions to do the same work (based on the compiler's knowledge of the data types). Some languages may avoid such extra work on the compiler by stating something like

The result of E1 >> E2 is E1 right-shifted E2 bit positions. [...] If E1 has a signed type and a negative value, the resulting value is implementation-defined.

Source : C language : ISO/IEC 9899:TC2 section 6.5.7 (Bitwise shift operators)

Type and signedness aren't part of the data itself. The knowledge was already used to generate the instructions that use the data according to their actual type. For dynamic type evaluation (at runtime, see dynamic programming language), some kind of tags (many implementations are possible) are added in the data structures to identify their type, and use the appropriate code to handle it.