On Tue, Jun 23, 2015 at 02:33:51PM -0700, Philip Guenther wrote: > On Tue, Jun 23, 2015 at 1:18 PM, Mike Larkin <[email protected]> wrote: > > On Tue, Jun 23, 2015 at 09:49:26AM +0300, Alexey Dobriyan wrote: > >> Clearing 32-bit register clears whole register, save REX prefix. > > > > I see nothing documented in the Intel SDM that says this. Can you cite > > a reference to support this claim? > > It's true. Volume 1, section 3.4.1 says this: > ---- > When in 64-bit mode, operand size determines the number of valid > bits in the destination 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 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. > ---- > > It's also mentioned in the optimization guide: > ---- > 9.2.1 Use Legacy 32-Bit Instructions When Data Size Is 32 Bits > > 64-bit mode makes 16 general purpose 64-bit registers available to > applications. If application data size > is 32 bits, there is no need to use 64-bit registers or 64-bit arithmetic. > > The default operand size for most instructions is 32 bits. The > behavior of those instructions is to make > the upper 32 bits all zeros. For example, when zeroing out a register, > the following two instruction > streams do the same thing, but the 32-bit version saves one instruction byte: > 32-bit version: > xor eax, eax; Performs xor on lower 32bits and zeroes the upper 32 > bits. > > 64-bit version: > xor rax, rax; Performs xor on all 64 bits. > ---- > > > > An aside - even if this were true, I still prefer xorq and the extra > > rex prefix byte because it more correctly conveys the intent of the > > programmer. > > I disagree. > > > Philip Guenther >
Then please go ahead and commit the change. No further objection from me. -ml
