How are Signed integers different from unsigned integers once compiled
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.