Index
> Main > Extend sign to 64-bit register |
| Author |
|
|
Tomasz Grysztar 05 May 2006, 11:21
CDQE
MOVSXD |
|||
05 May 2006, 11:21 |
|
|
MazeGen 05 May 2006, 14:12
It is funny that Intel chose different mnemonic (MOVSXD instead of MOVSX) for the same operation. It is probably because MOVSXD uses completely different opcode than original MOVSX instructions.
|
|||
|
05 May 2006, 14:12 |
|
|
Tomasz Grysztar 05 May 2006, 14:59
Perhaps also to keep the symmetry between MOVSX and MOVZX, as there is no MOVZXD (since simple 32-bit MOV is enough for that purpose).
|
|||
|
05 May 2006, 14:59 |
|
|
alorent 05 May 2006, 23:18
Thanks Tomasz!
Btw, I put MOVSXD RAX, EAX and FASM generated the opcode: MOVSXD RAX, R10D Is this a bug in FASM? CDQE worked fine 
Thanks. |
|||
|
05 May 2006, 23:18 |
|
|
LocoDelAssembly 05 May 2006, 23:29
For me:
Code: use64 MOVSXD RAX, R10D ; 49 63 C2 MOVSXD RAX, EAX ; 48 63 C0 [edit]FASM 1.64 generates a completelly different encoding :S Code: use64 MOVSXD RAX, R10D ; 48 63 E4 MOVSXD RAX, EAX ; 48 63 E4 Last edited by LocoDelAssembly on 06 May 2006, 13:13; edited 1 time in total |
|||
|
05 May 2006, 23:29 |
|
|
MazeGen 06 May 2006, 06:23
Tomasz Grysztar wrote: Perhaps also to keep the symmetry between MOVSX and MOVZX, as there is no MOVZXD (since simple 32-bit MOV is enough for that purpose). I really dislike these inconsistencies in x86-64. I'm writing INVOKE macro for MASM. Integer arguments are sign-extended to 64 bits. If an argument is high 8-bit register, I have to use temporary register, because those registers are not encodable with MOVSX. If an argument is 16-bit one, MOVSX work just fine. If an argument is 32-bit one, I have to use MOVSXD instead of MOVSX. I hope there will be no third patch, x86-128 architecture  |
|||
|
06 May 2006, 06:23 |
|
|
Tomasz Grysztar 06 May 2006, 11:28
locodelassembly: you wrote in one place C3 instead of 63. I assume it's a mistake?
MazeGen: if this is the amd64 fastcall convention, the parameters that are smaller than 64 bits don't need to be extended, the higher bits are assumed to be garbage, so the simple "mov [esp+xx],ah" is enough - this way the fasm's 64-bit invoke macro works. Or perhaps I did mistunderstood what are you doing. |
|||
|
06 May 2006, 11:28 |
|
|
MazeGen 06 May 2006, 11:43
Tomasz: It seems that different documents say different things. I actually come from newer Matt Piertek's article:
Quote: First, integer parameters that are less than 64-bits are sign extended, then still passed via the appropriate register, if among the first four integer parameters. On the other side, MSDN says pursuant to you: Quote: All arguments are right justified in registers. This is done so the callee can ignore the upper bits of the register if need be and can access only the portion of the register necessary. Now I wonder what is the right way... Please, could you tell me where could I find your INVOKE macro? I'm not so familiar with FASM package. Thanks. |
|||
|
06 May 2006, 11:43 |
|
|
Tomasz Grysztar 06 May 2006, 12:04
The earliest version you can find here: http://board.flatassembler.net/topic.php?t=4209
It may be still interesting, since it implements the "stack reuse" technique (there's a small bug, however, as I forgot to keep the 16-byte alignment). The final macros do stack allocation for each call separaterly, to make those macros just easier to use (and thus leaving you to write the stack reusing calls manually if you need more optimization). The current PROC64.INC is in the fasmw package in INCLUDE/MACRO directory. |
|||
|
06 May 2006, 12:04 |
|
|
Tomasz Grysztar 06 May 2006, 12:16
PS. That's funny, but the fragment of Matt Piertek's arcticle that you quoted, provides as a reference the same link that I provided, which tells something exactly opposite.
|
|||
|
06 May 2006, 12:16 |
|
|
MazeGen 06 May 2006, 12:34
Thanks, Thomasz. I forgot about that thread. I'll study your macro.
Yeah, the 16-byte alignment is annoying. I use the GoAsm's approach for now. Yeah, the documentation is messy  . I probably stick to the sign extension for now. If I'll see it is unnecessary I remove it. |
|||
|
06 May 2006, 12:34 |
|
|
LocoDelAssembly 06 May 2006, 13:14
Tomasz Grysztar wrote: locodelassembly: you wrote in one place C3 instead of 63. I assume it's a mistake? Yep, sorry  |
|||
|
06 May 2006, 13:14 |
|
|
vid 09 May 2006, 08:54
btw, how is it with 16b alignment. i was already discussing it in private with MazeGen, and to me it seems that it is only required because of XMM registers, which need to be aligned. That would mean that alignment only needs to be justified for arguments of system calls, but in code you can use push rax or so...
(btw, i still have quite mess in this area, maybe what i am saying is complete ****) |
|||
|
09 May 2006, 08:54 |
|
|
MazeGen 09 May 2006, 16:27
I'm still unsure too. As for parameter passing, there is no reason to align the stack to 16 bytes because any parameter is 8 bytes big.
The only idea which comes to my mind is saving non-volatile XMM registers by the callee (by WinAPI function etc.). The callee (should use)/(probably uses) quick MOVDQA instruction in this case and therefore needs 16-byte alignment. |
|||
|
09 May 2006, 16:27 |
|
< Last Thread | Next Thread > |
Forum Rules:
|