mov     ax,35000
mov     bx,4096
div/idiv bh

why is it that i get a dividle by zero error when i do this.

What Ive done so far..
DIV: Please double check i might have messed up.
ax = 88B8h
bh = 10h

IDIV: Please double check i might have messed up.
ax = 7748h
bx = 10h

Is it because of the remainder that i get this problem?
Im not sure why...
Any help.


And one more thing when i do use a OP like IDIV only if the MSB is one then it dose the 2's complement of the number right?

Thanx in advance.

Recommended Answers

All 3 Replies

NOTE: I just wanted to make this clear. Its supposed to give back a Divide by Zero error, thats the point. I just dont understand why it dose give it back because Im dividing by 10h

I see what you mean in respect to the first example and the only conclusion I can come too is although new processors are backward compatible, but there are problems when attempting to use the high order bits of a 16 bit value. If you have access to a 286, see if there is a difference.

The remainder problems, I can't really figure out what your driving at there, but using the bx or bl registers does give me the desired result of 774 in ax and 8 in dx

I think i found out what the point of the problem is:

mov      ax,35000
mov      bx,4096
div/idiv  bh

DIV:
ax = 88B8h
bh = 10h
When you divide ax by bh you get a number that is bigger than 255. This causes an overflow to occur there for giving you a trap error. But for some reason when i run it in the debugger i get a div by zero error. I think the point is, is that you get an error.

IDIV:
ax = 7748h
bx = 10h
Same as above but instead of 255 its 127 because the IDIV allocates the MSB for signed numbers.

Thanx for the help.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.