which is faster before a I/DIV, XOR EDX, EDX or CDQ?im AMD XP

They seem to be equal at 1 cycle

Since your invalidating the cache after your instruction it would probably not depend a lot on your code sequence.

Not sure about the amd effect.

I'm running athlon also.

:alright:

Since your invalidating the cache after your instruction it would probably not depend a lot on your code sequence.

Not sure about the amd effect.

I'm running athlon also.

:alright:

If you are doing a signed division of the content of EAX, NEVER use the XOR EDX,EDX operation. You would definitely get the wrong answer if your number in EAX is negative.

On the other hand, if you do an unsigned division of the content of EAX, ALWAYS use the XOR EDX,EDX operation. Otherwise, you would then get the wrong answer if your number is larger than 32767. (Actually, your program would crash in the latter case.)

Raymond

On the other hand, if you do an unsigned division of the content of EAX, ALWAYS use the XOR EDX,EDX operation. Otherwise, you would then get the wrong answer if your number is larger than 32767. (Actually, your program would crash in the latter case.)

Raymond

Sorry about that "small" mental error in my last post. The 32767 would apply to AX for unsigned divisions of DX:AX. Since we are talking about EAX, 2147483647 is the largest number before it would become a "negative" number.

Raymond

Raymond

im using IDIV i forget if this is signed or unsigned, but i have a XOR EDX,EDX on it right now and its 100% correct.

Both are DirectPath instructions and have 1 clock latency; cdq is 1 byte vs. 2 for xor edx, edx.

If xor before the division is correct, then we're talking unsigned longs; cdq (operation: edx:eax <- SignExtendTo64Bit(eax)) will work as long as the numbers are < 2^31.

HTH

Jan

If xor before the division is correct, then we're talking unsigned longs; cdq (operation: edx:eax <- SignExtendTo64Bit(eax)) will work as long as the numbers are < 2^31.

HTH

Jan

2^31 is +2 off, correct is 256^4

Qages

I agree that the result will be correct if the number in EAX is positive. Sign extending such a number would put 0's in EDX, which you are doing with XOR EDX,EDX.

What I was trying to explain, is that you would normally use the IDIV instruction whenever you don't know if that number will be positive or negative. In such cases, you MUST use the CDQ instruction to make sure that you get the proper sign extension.

In this context, unless you know that your number in EAX would ALWAYS be positive AND could be divided by a positive or negative number, it becomes immaterial whether CDQ or XOR EDX,EDX is faster or not when using the IDIV instruction.

Similarly, when you would use the DIV instruction, you are insisting on making an unsigned division, specifying that both parameters are positive. In such cases, you do NOT want to risk extending a potential negative sign bit of EAX into EDX by using the CDQ instruction.

Raymond

I agree that the result will be correct if the number in EAX is positive. Sign extending such a number would put 0's in EDX, which you are doing with XOR EDX,EDX.

What I was trying to explain, is that you would normally use the IDIV instruction whenever you don't know if that number will be positive or negative. In such cases, you MUST use the CDQ instruction to make sure that you get the proper sign extension.

In this context, unless you know that your number in EAX would ALWAYS be positive AND could be divided by a positive or negative number, it becomes immaterial whether CDQ or XOR EDX,EDX is faster or not when using the IDIV instruction.

Similarly, when you would use the DIV instruction, you are insisting on making an unsigned division, specifying that both parameters are positive. In such cases, you do NOT want to risk extending a potential negative sign bit of EAX into EDX by using the CDQ instruction.

Raymond