Jeremy, is it to break a dependence ? (Re: your "Writing 64-bit Programs" page)

[Apl_and_Asm]

In the first example of the section "Some pitfalls to avoid when converting existing source code" (on your "Writing 64-bit Programs" page):

XOR RAX,RAX                              ;zero rax
MOV EAX,[SYSTEM_INFO+4h]        ;get page size into lower 32-bits of rax
ARG 4000h,RAX,[MEMORY_END]
INVOKE VirtualFree                       ;decommit a page of memory


As you many times pointed it out, an operation on the (whole) low dword of a quadword register zeroes its 32 upper bits.
So, did you use the low-cost (decoded but not passed to execution units) "XOR RAX, RAX" to break a dependence on
RAX' s 32 upper bits which could induce a penalty when (whole) RAX is read (partial register stall) ?
Or did I miss something ?

Regards.

[jorgon]

Hi Apl_and_Asm

Sorry for the delay in responding.

You're quite right about this.  There is really no need for the XOR RAX,RAX line bearing in mind the top part of RAX will be zeroed anyway by the next instruction moving something into EAX.  The main point I was making in the example was that in 64-bit source if you push anything onto the stack you will be pushing 64-bits of data, so you need to be sure that the source of that data is adjusted to suit.  Removing the XOR RAX,RAX line from the example complicates the point being made, so in future versions of this file I shall add a comment that the XOR RAX,RAX line can in fact be omitted.  Thanks for pointing this out.

I doubt if there are any performance implications of zeroing RAX first, since the MOV instruction probably does the same thing (as far as the high part of RAX is concerned) a second time anyway.  However, I do stand to be corrected on this.