If CPU executes a 64 bit code segment:
MOV  EAX, 5

Will the upper 32 bits of RAX become zero?


Posted on 2010-06-12 23:47:50 by logicman112
No.

OK to understand why not, lets step down one notch.

MOV AX, 5

Does this mess with the value of AH (the upper 16 bits) ?
Posted on 2010-06-13 00:27:11 by Homer
Yes, the upper bits will be zero -

When in 64-bit mode, operand size determines the number of valid bits in the desti-
nation general-purpose register:
64-bit operands generate a 64-bit result in the destination general-purpose
register.
32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the
destination general-purpose register.
8-bit and 16-bit operands generate an 8-bit or 16-bit result. The upper 56 bits or
48 bits (respectively) of the destination general-purpose register are not be
modified by the operation. If the result of an 8-bit or 16-bit operation is intended
for 64-bit address calculation, explicitly sign-extend the register to the full
64-bits.
Posted on 2010-06-13 05:22:21 by f0dder
Why the hell have they done that?
Posted on 2010-06-13 05:29:14 by Homer
This introduces a HELL of a lot of confusion.

According to some skimming I did today:
MOVZX EAX, AX WILL trash the upper 32 bits of RAX, regardless that the targetsize of this legacy 32bit instruction is explicit.
MOVZXD RAX, AX will NOT trash the upper 32 bits, regardless that the targetsize of this NEW 64BIT INSTRUCTION is explicit.

WHAT THE HELL ARE THESE CLOWNS DOING?
I'm sure it's very useful to be able to clear the top 32 bits, but what if I didnt want to?
Is it only MOV-related instructions that are affected by this?
Posted on 2010-06-13 05:44:05 by Homer

This introduces a HELL of a lot of confusion.

According to some skimming I did today:
MOVZX EAX, AX WILL trash the upper 32 bits of RAX, regardless that the targetsize of this legacy 32bit instruction is explicit.
MOVZXD RAX, AX will NOT trash the upper 32 bits, regardless that the targetsize of this NEW 64BIT INSTRUCTION is explicit.


MOVZXD doesn't exist in long mode, as MOV does the same thing.


WHAT THE HELL ARE THESE CLOWNS DOING?
I'm sure it's very useful to be able to clear the top 32 bits, but what if I didnt want to?
Is it only MOV-related instructions that are affected by this?


I'm guessing for "optimization" purposes, but one person's optimization is another person's bane.

Perhaps this simplifies the chip design, especially with regard to compatibility mode?

In the end, I would have liked it to be consistent as well :sad:
Posted on 2010-06-13 12:25:52 by SpooK