x64 dword parameter question

[Elegant]

Just looking to check something, say I call this procedure that takes 4 arguments:

Code Select Expand


;var1:qword,var2:qword,var3:dword,var4:dword

;Now this goes into rcx,rdx,r8,r9 for the below function as follows
;var1=rcx
;var2=rdx
;var3=r8d
;var4=r9d

myFunction proc public frame
...
   add rax,r8
   add rbx,r9
...


Are var3 and var4 able be used safely as r8 and r9 instead of just r8d and r9d? Is the upper 32 bits zero'd or am I potentially introducing something unwanted? I realize "add eax,r8d" works as well but the above example allows for larger values with rax.

[rrr314159]

It should work fine but depends on the caller. Presumably you're calling myFunction from a C program? (you can't be calling from JWasm because your proc statement would have to include the parameters var1, var2 etc). So, the C program should handle the upper 32 bits correctly, either zero or sign-extend if that's applicable. I'd be amazed if it didn't do it right, but it depends on the competence (or lack thereof) of the writers of your C compiler. The assembler code, myFunction, compiled by MASM (or JWasm, whatever), has nothing to do with it

[qWord]

Are var3 and var4 able be used safely as r8 and r9 instead of just r8d and r9d?

The content of the upper bits is undefined as long as you did not control all possible calls.

[Elegant]

So it comes down to what the C++ compiler with VS2013 does with the function call. I would hope that they have that covered and zero the upper 32bits or use the same process that movsxd does since they document that operation, leaving them undefined could potentially lead to issues. Mind you I'm not noticing any out of the ordinary right now.