MOV EAX,12345678h ;Value to be Divided
MOV ECX,02h ;Value to Divided with
CDQ ;Convert into QWORD
DIV ECX ;Run Divide Process

MOV EAX,12345678h ;Value to be Divided
MOV ECX,02h ;Value to Divided with
CDQ ;Convert into QWORD
IDIV ECX ;Run Divide Process


when I run this I get the same result with both..

the intel book just says CDQ converts a DWORD to a QWORD nothing of it having to be signed or un-signed
so i figure it can be used in either case with out messing anything up.

DIV does standard division which I understand

now the thing I dont get is IDIV

it seems to beable to use both signed and non signed... is this true. to me I would think it would be bad to use IDIV for all cases of division math..

the above is non signed i know but how do i tell the CPU that it is signed before processing it..
Posted on 2003-09-28 02:17:28 by devilsclaw
the 2 snipplet produce different results if the input is a negative number. Let's say the number in eax = -3, and ecx = 3

For the first snipplet, the output would be -1.

But for the second, the output would be 5555555555555554h.
Posted on 2003-09-28 03:44:37 by roticv



the intel book just says CDQ converts a DWORD to a QWORD nothing of it having to be signed or un-signed
so i figure it can be used in either case with out messing anything up.

DIV does standard division which I understand

now the thing I dont get is IDIV

it seems to beable to use both signed and non signed... is this true. to me I would think it would be bad to use IDIV for all cases of division math..

the above is non signed i know but how do i tell the CPU that it is signed before processing it..

A signed number's most significant bit tells whether it's positive or negative. A signed number is positive or negative, it doesn't have to be negative.
CDQ works on signed numbers, all it does is clear edx and move the most significant bit from eax to edx.
If you wish to extend an unsigned number just clear edx.
IDIV works on signed numbers only.
Posted on 2003-09-29 07:43:18 by _js_
For the first snipplet, the output would be -1.

But for the second, the output would be 5555555555555554h
The IDIV instruction (which is the 2nd snippet) would produce the -1 result in EAX (and the remainder in EDX would be 0). The DIV instruction (which is the 1st snippet) would produce an OVERFLOW ERROR (and crash the program) after extending the sign bit into EDX.

Raymond
Posted on 2003-09-29 23:01:48 by Raymond
Whenever you assume something, you risk being wrong half of the time.
Yes. ;)

what is 0FFh?
255?
-1?
or may be FALSE?

:grin: :alright:
Posted on 2003-09-30 02:53:16 by S.T.A.S.
IF 0FFh is the value of a BYTE, it is equal to 255 if it is considered as unsigned or equal to -1 if it is considered as signed.

IF 0FFh is the value of a WORD or of a DWORD, it is always equal to 255.

When used with Windows API functions, FALSE is an EQUATE for 0.

Raymond
Posted on 2003-09-30 23:39:29 by Raymond
... it is considered ...

this is the basis of the matters, imho :)

thanks
Posted on 2003-10-02 18:11:34 by S.T.A.S.
Generally speaking a number of N bits ranges in value:

Signed:

- 2^(N-1) thru 2^(N-1) - 1

Unsigned:

0 thru 2^N - 1


If you want to test the difference between signed and unsigned operations then you must use values that do not translate directly from signed set value to unsigned set value. Therefor signed numbers less than 0, and unsigned numbers greater or equal to 2^(N-1).
Posted on 2003-10-02 20:05:34 by bitRAKE
The only thing I wished to say is:

Everithing depends on our consideration.
All these bytes are just combination of some voltages :cool:
If we want to "see" them, we should convert to a form that human can understand

Also, we could use the lowest bit as a sign, not so easy, but still...
This is the power of asm :)

This is just some kind of my madness
:stupid:
Posted on 2003-10-02 20:53:09 by S.T.A.S.