Divide 15 by 52, getting overflow.

[RalphyWiggum]

Sorry, I am kinda new at assembly language, hopefully someone can help. To the end of my simple program, I "mov" my variable "clutchbell" that a user enters a value of "15" into "ebx", then I "div" a variable "spurgear" that a user enters a value of "52". The result is 0.28846153846153846153846153846154 and this is stored in the remainder "edx" right? Well I get a overload for obvious reasons...although I am only interested in the first (3) places after the decimal. Is there a way that I can isolate and store the value .288 into "edx"...see a snipett below.

mov ebx, clutchbell ; clutchbell to EBX
div spurgear ; divide
dtoa ratio, edx
output label1

 

[AirCon]

First, division (DIV) is always against register EAX.
e.g.:
mov eax, 10
mov ebx, 13
div ebx
; divide eax with ebx
; 10 / 13

the results is
eax = 0
edx = 13 -> this is the REMAINDER

So you won't get floating point as the results. If you want to get FLOAT then you must use FPU (Floating Point Unit)instruction

Hope it helps a little

-- AirCon --

 

[AirCon]

Oops.. a mistake! Sorry

The results should be like this
eax = 0
edx = 10 -> this is the REMAINDER


-- AirCon --

 

[AirCon]

Arggh..
One more thing about division. You must always make sure that EDX is zero before division

-- AirCon --

 

[lionelhill]

Sorry, feeling thick today....
Why does edx need to be zero?

 

[RalphyWiggum]

Sorry, I am still not exactly clear on how I isolate the first 3 digits after the decimal point. Also I don't see how dividing 10 by 13 gives you a remainder of 10. Could you please provide more detail or give me some helpful links. Thanks!

 

[zeitghost]

This bit of C does the same integer arithmetic....

int main()
{

int i,j,ans,rem

i=10;
j=13;
ans = i/j;
rem = i%j;

printf( "ans %d remainder %d", ans, rem );
}

If you want to get floating point results you have to use the numeric coprocessor with floating point numbers!

rgds
Zeit.

 

[AirCon]

Lionel
I don't have an exact answer about why edx must be 0. I never even read about that either. Just from my experience that if edx is not 0, we can get the weird result. Even worst it could raise an error if we are in the loop or edx contains a real number.

So I ran (in windows) a small test about this, here is the result:
mov edx, 1
mov eax, 10
mov ebx, 13
div ebx

results:
eax = 13B13B14h
edx = 6

but if edx is 0 then I got the correct one (eax=0, edx=10). If someone knows the reason exactly, please explain


Ralphy
What DIV (unsigned) & IDIV (signed) does actually is an integer division, even if you put a float number into it. So the results of this instruction is what we called "quotient" and "remainder". I think Zeitghost example has cleared it up. If you still have not cleared about this, just ask

Ok, here is a floating point example:

.data
cluthbell REAL4 15.0 ; REAL4 is FLOAT in C
spurgear REAL4 52.0
ratio REAL4 0.0

.code
fld cluthbell ; put in the value from cluthbell
fdiv spurgear ; divide by spurgear (real division)
fstp ratio ; store the results into ratio and pop

Now "ratio" is the contain a real number. But it's in IEEE Packed BCD format. So you must learn IEEE if you want to get the value into decimal format (0.288xxxx). Or if you have MASM32 package you can look for the lib called FloatToStr (for double / 64 bit).

Regards

-- AirCon --

 

[lionelhill]

AirCon, being embarassed I checked up (I haven't used a div for quite a while, and then it was by a byte). If you divide by a word, processor assumes you might want to be dividing a dword, since that's the biggest thing that you can divide by a word and still have a word-size remainder (for dx) and word-sized result (for ax), and therefore it takes a dword thing to divide, from dx and ax. Presumably if you're in 32 bit then it uses edx and eax to handle a 64-bit number?
Actually I must have known that once, because last time I did a div using word operand I duly had sub dx, dx before hand, but I must have looked it up at the time and forgot.
Haven't checked your example, but I assume that's why it gave the result it did...
Thanks!

 

[AirCon]

Ahh..you are right Lionel. I also wrong when I said edx must always 0.

So a correction to my last statement:
It doesn't have to be edx, but more precisely is the "remainder register" must be 0.

But I still don't know the reason why this remainder register interfere if we don't clear it up. I must be missing something here *ugghh*

-- AirCon --

 

[lionelhill]

It's not only the remainder! It's also the high word/dword of the numerator...
Strange how being brought up in 6502 world has left me loath to use div, even when it's quite a respectable instruction.