flat assembler
Message board for the users of flat assembler.

Index > Main > Extend sign to 64-bit register

Author
Thread Post new topic Reply to topic
alorent



Joined: 05 Dec 2005
Posts: 201
alorent
Hello,

Is there any instruction that sign extend from a 32-bit register to 64-bit?

For example, I have:

EAX = 0FFFFFF12h

and I want to extend it to:

RAX = 0FFFFFFFFFFFFFF12h

I thought the MOVSX instruction might work, but it only works to extend 8 and 16-bit registers.

Thanks.
alorent
Post 05 May 2006, 11:00
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7618
Location: Kraków, Poland
Tomasz Grysztar
CDQE
MOVSXD
Post 05 May 2006, 11:21
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 959
Location: Czechoslovakia
MazeGen
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.
Post 05 May 2006, 14:12
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7618
Location: Kraków, Poland
Tomasz Grysztar
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).
Post 05 May 2006, 14:59
View user's profile Send private message Visit poster's website Reply with quote
alorent



Joined: 05 Dec 2005
Posts: 201
alorent
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 Wink

Thanks.
Post 05 May 2006, 23:18
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
For me:
Code:
use64 
MOVSXD RAX, R10D ; 49 63 C2
MOVSXD RAX, EAX  ; 48 63 C0    
I'm using FASM 1.65.21

[edit]FASM 1.64 generates a completelly different encoding :S
Code:
use64
MOVSXD RAX, R10D ; 48 63 E4
MOVSXD RAX, EAX  ; 48 63 E4     
And uses the same encoding for both instructions[/edit][edit2]Corrected encoding of MOVSXD RAX, R10D [/edit2]


Last edited by LocoDelAssembly on 06 May 2006, 13:13; edited 1 time in total
Post 05 May 2006, 23:29
View user's profile Send private message Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 959
Location: Czechoslovakia
MazeGen
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 Laughing
Post 06 May 2006, 06:23
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7618
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 06 May 2006, 11:28
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 959
Location: Czechoslovakia
MazeGen
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.
Post 06 May 2006, 11:43
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7618
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 06 May 2006, 12:04
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7618
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 06 May 2006, 12:16
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 959
Location: Czechoslovakia
MazeGen
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 Sad. I probably stick to the sign extension for now. If I'll see it is unnecessary I remove it.
Post 06 May 2006, 12:34
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Tomasz Grysztar wrote:
locodelassembly: you wrote in one place C3 instead of 63. I assume it's a mistake?


Yep, sorry Embarassed
Post 06 May 2006, 13:14
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
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 ****)
Post 09 May 2006, 08:54
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 959
Location: Czechoslovakia
MazeGen
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.
Post 09 May 2006, 16:27
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.