I am having trouble understanding what is "correct" and not correct when doing addition and subtraction with hex values as far as the signed representation. I'd like to point out that I'm going to deal with BYTE sized data.
As an example, when I add 6C (hex) + 7D (hex), I get the answer E9 (hex). Now, from my standpoint, I KNOW that E9 is the correct answer as an unsigned integer. 108 (6C) + 125 (7D) = 233 (E9)
However, my problem arises when I try to determine if this is the correct answer as a signed answer...
Should I be thinking about the logic of the INITIAL addition?? (and state that E9 is incorrect since 6C (A positive) + 7D (a positive) CANNOT equal E9 (a negative in signed notation) since adding 2 positives can't make a negative..)
... OR should I be stating that E9 is incorrect because it is out of range [-128,+127]
.. OR should I look at it completely differently, take the 2's complement of 7D and subtract that from 6C and see if that answer fits into place to determine if its correct or not?
Basically, I just need to be pointed in the right direction for what to look for in regards to determining if the signed version of an answer it correct or not. I like step by step instructions for these types of things, but my assembly language book isn't helping too much.
binary addition has no notion if signed vs unsigned. exactly the same the bit patterns. The meaning of those bit patterns is in the eyes of the beholder (multiply and divide this is not true). This is the beauty of twos complement.
0xF0 + 0x02 = 0xF2 = 240 + 2 = 242
0xF0 + 0x02 = 0xF2 = -16 + 2 = -14
Subtraction to make your life easier
A - B = A + (-B) = A + (~B) + 1
Now signed and unsigned overflow are defined differently for addition and subtraction. So whether or not you get the "right" answer for signed or unsigned numbers is determined by if you get an overflow or not.
EDIT
6C + 7D = E9
108 + 125 = 233
108 + 125 != -23
yes there is a signed overflow, if you are treating these as signed numbers then you overflowed and the answer is wrong, If you are treating these as unsigned numbers you did not have an unsigned overflow the answer is right.
Unsigned overflow is just the carry out if the result requires 9 bits 1xx then that is an unsigned overflow. For signed overflow if the carry out of the next to msbit and the carry out of the msbit (or another way to say it is if the carry in and the carry out of the msbit do not match then it is a signed overflow). You have perhaps intentionally chosen numbers that make this really easy. The msbit of both operands is a 0, the carry in is a 1 because if these were 7 bit numbers that would have been a carry out. So the carry in to the msbit is a 1 the operands are 0 and 0 1+0+0 = 1 with a carry of 0, so the carry in is 1, the carry out is 0, signed overflow. If you do the analysis another way to test for signed overflow is if the msbit of the two operands are the same and the msbit of the result is not the same then that is a signed overflow.
basically this is that truth table
abi or
000 00
001 01 v
010 01
011 10
100 01
101 10
110 10 v
111 11
a and b are the msbits of the operands, i is the carry in, r is the result o is the carry out, if i and 0 dont match then it is a signed overflow. The two cases where this happens are also the two cases where a = b and b != r
so your two numbers looking at the msbits is 0 0 1, the operands match the result doesnt, signed overflow if this is signed addition then it failed you cannot represent the answer in the number of bits available.