Here is the scoop on DIV (your definition is quite convoluted):
Since we are dividing, you the computer expects that the operation will
create a smaller value that what it started with, (there is some problems
with this assumption, like divinde by 1).. but non the less, the cpu
works this way...
So.. if your dividing 16 bits by a 8 bit value, expect 8 bit answer, with
an 8 bit remainer. In this case, AX is the 16 source, and the answer is
then copied over the source with AL holding the answer, and AH holding
the remainder.
Likewise, if your dividing a 32 bit source by 16 bits, it will use DX as
the upper 16 bit source, AX as the lower 16 bit source, and divide the
equivelant 32bit number by a 16 value, producing a 16 bit answer in AX,
and a 16 bit remainder in DX.
The newer .386 intruction set provides for a 32 bit divisor as well, using
EDX as the upper 32 bits, and EAX as the lower 32bits of a 64 bit source,
and it is divided by 32 bits to produce a 32 answer in EAX and remainder
in EDX.
Hopefully this paints a better picture. The thing to remember about all
this, is the CPU only realizes the type of source to consider by the size
of the divisor.
Your source has:
div DelayMilli
Where delaymilli is defined as a Double 32 bits, so this would imply that the
upper 32bits to use is EDX and lower is EAX.
Since GetTickCount will return a DWORD in eax, there is no guarentees that
EDX will remain unchanged (M$ lazyness). So odds are, the invoke you called
will fill EDX with some random 32 bit number, compounded with the tickcount
in EAX, will make a very big 64 number to be divided by a relatively small
32 bit number (1000).. If the divisor is too small, the answer will outgrow
the size of the destination register (32 bits) and cause a divide overflow
error (a fatal error which will cause the program to crash).
If your still following all this, i would try adding this line:
invoke GetTickCount
mov edx, 0 ; format upper 32 bits of 64 bit source
div DelayMilli
...
Or... By the same logic, scale down your divsor data type.. 1000 out of 4 Gig
is small. At least 16 bits are 0's, you can easily fit 1000 in a word (16 bits),
however, DX will still be used, and thus you will still need to format it to
ensure no errors (it may not cause a divide overflow in this case, but you
could still have faulty answers if dx is allowed to hold a non zero value)..
[Another Fix]
DelayMilli dw 1000
invoke GetTickCount
mov edx, 0 ; format DX
div DelayMilli
...
Well that was much longer than first intended...
Hope it helps..
NaN
