subtraction in 8086

Thread Starter

cssc

Joined Oct 19, 2014
26
if i subtract 7986h from 0976h in a calculator, i got the answer as ffff8ff0
but when i did it in 8086 program, my answer was only 8ff0 (ofcourse with carry and sign flag set)
where can i find the upper 4 bits of the actual answer?
 

Papabravo

Joined Feb 24, 2006
15,698
You can do multiword subtraction but not in a single operation. The result depends on how you set the problem up.
Code:
0976h --> 0000 0976h
7986h --> 0000 7986h
The first subtraction produces 8ff0h as you have already observed
The second operation is a subtract with borrow
so 0 - 0 - borrow = ffffh
and those two parts produce the 32-bit result
See the description of sbb
http://ece425web.groups.et.byu.net/stable/labs/8086InstructionSet.html#sbb
 

WBahn

Joined Mar 31, 2012
26,398
so, can't i get the higher bits in some other register,as in case of multiplication.?
But then the next question would be: Isn't a "better" answer ffffffff8ff0h, so what register can I find the next 16 bits in? And the 16 beyond that?

When doing addition and subtraction with N-bit operands, you need at most N+1 bits to fully represent the result. You get this additional bit of information via the carry bit, so it is pointless to expend additional silicon to put one bit of information into an N-bit register. But with multiplication and division, you need 2N bits to fully represent the result, so here is DOES make sense to use a second N-bit register (not to mention the fact that a lot of silicon was added to support the operations to begin with).
 

MrChips

Joined Oct 2, 2009
23,204
This problem will exist regardless of the number of bits available in the register. Before you go performing arithmetic with fixed-sized registers you need to study the limits of the register.

What is the range of values that can be represented in an n-bit register?

What are the consequences when a math operation such as ADD, SUBTRACT and MULTIPLY exceed the range of the register?
 

upopads2

Joined Sep 20, 2014
54
Its been a while and I no nothing in comparison to chips but i believe when you exceed it is an overflow and so that changes your bits completely you now are starting back at the bottom of that register.
 

upopads2

Joined Sep 20, 2014
54
Whats embarrassing to me is I converted your hex values cssc to decimal and subtracted them in decimal getting (28688) in base 10 then converted back to base 16 and found that I got a much different value than you did, your "ffff8ff0".
 

WBahn

Joined Mar 31, 2012
26,398
Whats embarrassing to me is I converted your hex values cssc to decimal and subtracted them in decimal getting (28688) in base 10 then converted back to base 16 and found that I got a much different value than you did, your "ffff8ff0".
It would really help if you showed your steps, because what little information you do give makes no sense.

7986h is a large positive number relative to 0976h, which is a smaller positive number. Subtracting 7986h from 0976h therefore results in a negative number.

7986h = 31110
0976h = 2422

2422 - 31110 = -28688

-28688 = 8ff0h

If you got 7010h, it's because you forgot the most significant bit of all -- the sign bit!
 

upopads2

Joined Sep 20, 2014
54
It would really help if you showed your steps, because what little information you do give makes no sense.

7986h is a large positive number relative to 0976h, which is a smaller positive number. Subtracting 7986h from 0976h therefore results in a negative number.

7986h = 31110
0976h = 2422

2422 - 31110 = -28688

-28688 = 8ff0h

If you got 7010h, it's because you forgot the most significant bit of all -- the sign bit!

Sorry Bahn, forgot how to subtract.
 
Top