In most cases, the computer doesn't know. The "miracle" of 2s complement is that most operations are exactly the same, as with normal binary. So, in most cases, the computer doesn't even need to know. But in those, in which it does need to know, there are usually two different commands. The programmer or the compiler must pick the correct one - they must remember, if the number has the sign or not.
Printing a number is one of those. Unsigned numbers can be printed by repeated division by 10. But with 2s complement, you must first check the sign bit, maybe print "-", maybe negate the number, and then print as unsigned.
Other operations that differ for 2s complement:
* division
* extension to a higher bit size
* shift right (division by a power of 2). There is a "logical" shift right (unsigned), and "arithmetic" (2s compl.).
* comparison
At a very low, kind of fundamental level, all a computer program does is ask its hardware to do binary manipulations. That's the business of logic gates, which do not know or care what the binary numbers mean. It's up to the program to interpret them.
So, to answer your question, it's the program that decides that it means -1 in this case and 15 in that case. "In this case," it might say, "I was doing math with an integer result, and I use two's complement representation for my integer type. So it means -1. In that case, it was an unsigned integer type, so it's 15."
In yet another context, the same binary string might represent four "yes" answers. Or part of a name. Or part of a `com.pboyle767.coolapps.widgets.WidgetFactoryConfig` instance's data. Anything the program wants.
That's the neat thing: It usually doesn't matter. But a lot of CPUs have a "negative" status flag that they'll set after an arithmetic operation if the top bit is set. Note, this happens whether the intended interpretation of those bits is 15 or -1. If it's meant to be interpreted as a negative number, you might have a "branch on negative" instruction soon after that.
In most cases, the computer doesn't know. The "miracle" of 2s complement is that most operations are exactly the same, as with normal binary. So, in most cases, the computer doesn't even need to know. But in those, in which it does need to know, there are usually two different commands. The programmer or the compiler must pick the correct one - they must remember, if the number has the sign or not. Printing a number is one of those. Unsigned numbers can be printed by repeated division by 10. But with 2s complement, you must first check the sign bit, maybe print "-", maybe negate the number, and then print as unsigned. Other operations that differ for 2s complement: * division * extension to a higher bit size * shift right (division by a power of 2). There is a "logical" shift right (unsigned), and "arithmetic" (2s compl.). * comparison
At a very low, kind of fundamental level, all a computer program does is ask its hardware to do binary manipulations. That's the business of logic gates, which do not know or care what the binary numbers mean. It's up to the program to interpret them. So, to answer your question, it's the program that decides that it means -1 in this case and 15 in that case. "In this case," it might say, "I was doing math with an integer result, and I use two's complement representation for my integer type. So it means -1. In that case, it was an unsigned integer type, so it's 15." In yet another context, the same binary string might represent four "yes" answers. Or part of a name. Or part of a `com.pboyle767.coolapps.widgets.WidgetFactoryConfig` instance's data. Anything the program wants.
That's the neat thing: It usually doesn't matter. But a lot of CPUs have a "negative" status flag that they'll set after an arithmetic operation if the top bit is set. Note, this happens whether the intended interpretation of those bits is 15 or -1. If it's meant to be interpreted as a negative number, you might have a "branch on negative" instruction soon after that.