Question

How does the microprocessor differentiate among positive numbers , negative numbers and a bit pattern?

Answer 1

Throughout this answer I’ll occasionally use some binary numbers and for the sake of simplicity they’ll all be 4 bit)

Normally (there have been “abnormal” processors :-)) what’s used in todays processors is a number representation called “”. In this representation the sign of a number is quite easily deduced by a look at the MSB (Most Significant Bit): If this bit is a 0, then the number is positive, if this bit is 1, the number is negative.

Up to here it’s pretty straightforward, but it gets a little bit more complicated as to the value of the number. Actually not for the positive numbers - for them everything is “normal” except that you have to watch out for the sign bit. Now, for negative numbers the first instinct is to use the same value encoding, just with the sign bit indicating a negative number. This scheme has it’s own name: “”.

At a first glance this looks quite logical and easy to use but it does have quite a few problems:

You have two representations for 0. One is a +0: 0000 and the other one being a -0: 1000. This isn’t nice to begin with.
You can not use a normal full adder to add and/or subtract numbers. You always have to separate the sign bit from the value bits first, then use the sign bits to find out wich operation to perform, make the addition/subtraction for the value bits and then use the result with the sign bits of the operands to determine the sign of the result. Very very tedious to do.
So, one day a smarter than usual guy (Wikipedia say it was von Neumann) proposed the two’s complement system that eliminates a lot of those problems:

In this system, a negative number is created by taking the positive number, invert all the bits and then add 1 and the same for getting the positive number from a negative one. For example, lets see how that works out for the number 3:

0011 with all bits inverted is 1100; then we add one and get 1101. So, the representation of -3 is; 1101. And back: 1101 inverted is 0010 add one to that and you have 0011 again. Magic!

What happens with 0? Let’s check: 0000 inverted is 1111 and add 1 you get 0000. More Magic!

“How does that help anything?” you ask and the answer is: you can now use your old adder from your pre signed numbers era and use this to add positive and negative numbers without the slightest problem! Let’s add 4 and -3:

0100 + 1101 = 0001

As you should be aware, 4 + (-3) is the same as 4 - 3, so you immediately have your recipe for subtraction: create the two’s complement of your second operand and add! As the conversion of a number to it’s two’s complement does only need addition as well, this reduces the complexity of your hardware greatly.

Of course, this scheme also has it’s own problems:

Overflow: add for example 7 + 2 and you get: 0111 + 0010 = 1001 which is in the two’s complement the representation for -7. So, add two postive numbers and the result could be negative.
It’s easy to see, that the biggest positive number is +7; not so easy to see is, that the biggest negative number is actually -8 (1000). So, the range is asymmetrical - for 4bits it’s +7 to -8, for 8bits it’s +127 to -128.
The second “problem” is actually the reason that in practically ALL programming languages you’ll come across the integers have such a fancy asymmetrical range, where the biggest negative number is just 1 bigger than the biggest positive number.

“problem” 1 is the reason you must always be careful with adding things up, as you can easily end up with a negative result fromm adding up a bunch of all positive numbers. (And no, that’s not the reason some people try to tell you that the sum of all positive numbers from 1 to infinity is -1/12)

All in all, the benefits of the two’s complement representation far outweighs its problems, so it’s practically used in every microprocessor today. (At least I don’t know a single one that doesn’t)
mark it as brainliest