flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Bug with movsxd

Author
Thread Post new topic Reply to topic
Xorpd!



Joined: 21 Dec 2006
Posts: 161
Xorpd!
Code:
C:\Asm\FASM\Bugs>type bug1db.asm
format MS64 coff

section 'CODE' code readable executable align 16
align 16
public MOVSXDTEST
MOVSXDTEST:
   db  63h, 0c1h
   ret

C:\Asm\FASM\Bugs>fasm bug1db.asm
flat assembler  version 1.67.18  (1299284 kilobytes memory)
1 passes, 114 bytes.

C:\Asm\FASM\Bugs>dumpbin /disasm bug1db.obj
Microsoft (R) COFF/PE Dumper Version 8.00.50727.363
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file bug1db.obj

File Type: COFF OBJECT

MOVSXDTEST:
  0000000000000000: 63 C1              movsxd      eax,ecx
  0000000000000002: C3                 ret

  Summary

           3 CODE

C:\Asm\FASM\Bugs>type bug1mn.asm
format MS64 coff

section 'CODE' code readable executable align 16
align 16
public MOVSXDTEST
MOVSXDTEST:
   movsxd eax, ecx
   ret

C:\Asm\FASM\Bugs>fasm bug1mn.asm
flat assembler  version 1.67.18  (1299267 kilobytes memory)
bug1mn.asm [7]:
   movsxd eax, ecx
error: invalid size of operand.
    
Post 06 Jan 2007, 09:08
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
Intel manual wrote:
The use of MOVSXD without REX.W in 64-bit mode is discouraged, Regular MOV should be used instead of using MOVSXD without REX.W.
Strictly speaking I guess the disassembly you show above is correct. Of course a standard MOV gives the same result.

Seems to me to be a philosophical thing, should fasm support 'MOVSXD r32,r32', disallow it (the current behaviour) or change it to MOV?
Post 06 Jan 2007, 11:31
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
This is the same problem as whether to allow "MOVZX AX,CX" (and thus much older thing). When writing fasm I assumed these are nothing else are another forms of MOV.
Post 06 Jan 2007, 11:50
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
I don't think it would be much of use, but the assembler should allow the same size of operands in MOVSX, MOVZX and MOVZXD since such operands are encodable.
Post 07 Jan 2007, 17:34
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
But shouldn't this encoding be called a simple MOV instead? The manuals list MOVSX/MOVZX with forms of first operand being larger than the second one (well, for obvious reasons).
Post 07 Jan 2007, 23:05
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Essentually, think of his implimentation as assembler level optimization.
Post 08 Jan 2007, 05:24
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
Tomasz, that's interesting question. vid just confirmed that you said you think about asm as some higher abstraction of machine code. From this point of view, fasm should really return an error.

I like more "machine-driven way", because MOVZX AX,CX and MOV AX,CX are two different intructions at machine code level, but it is up to you, of course Smile
Post 08 Jan 2007, 13:13
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Yes, for me assembly syntax should focus on the functionality of the instruction, while choosing the encoding should be left to assembler. When by writing I was getting rid of a problem of having to define instructions with DBs I had in TASM, it was not because it did not generate some specific encoding that I wanted, it was because it did not allow to encode some specific instruction from functionality point of view.
The assembler in general provides a programmer with an abstraction layer that allows programmer to focus on what instruction does, not how exactly it is encoded.
The most basic example of this abstraction is with the LD and ST encodings of the MOV instruction (like 89-C8 and 8B-C1, which both encode MOV AX,CX). The fact that it isn't really important for programmer which encoding the assembler chooses, allows even to make the "imprint" of the assembler on the code it generates.
Post 08 Jan 2007, 16:09
View user's profile Send private message Visit poster's website Reply with quote
Xorpd!



Joined: 21 Dec 2006
Posts: 161
Xorpd!
We may be forced to admit defeat on this issue. First though, I would like to see how:
Code:
format MS64 coff

section 'CODE' code readable executable align 16
align 16
public MOVSXDTIME
MOVSXDTIME:
   mov r8, rbx
   mov r9d, 100
   rdtsc
   mov r10d, eax
   shl rdx, 32
   or r10, rdx
.loop_top:
repeat 10
   db 63h, 0c1h
   db 63h, 0d3h
   db 63h, 0c8h
   db 63h, 0dah
end repeat
   sub r9, 1
   jnz .loop_top
   rdtsc
   shl rdx, 32
   or rax, rdx
   sub rax, r10
   mov rbx, r8
   ret

align 16
public MOVTIME
MOVTIME:
   mov r8, rbx
   mov r9d, 100
   rdtsc
   mov r10d, eax
   shl rdx, 32
   or r10, rdx
.loop_top:
repeat 10
   mov eax, ecx
   mov edx, ebx
   mov ecx, eax
   mov ebx, edx
end repeat
   sub r9, 1
   jnz .loop_top
   rdtsc
   shl rdx, 32
   or rax, rdx
   sub rax, r10
   mov rbx, r8
   ret
    

performs on a P4. On other machines, the functions should be the same, e.g.:
[pre]
1 0000000000001252
2 0000000000001130
3 000000000000113A
4 0000000000001144
5 0000000000001144
6 0000000000001126
7 0000000000001144
8 000000000000113A
[/pre]
Where the first four lines are from MOVSXDTIME, and the last four from MOVTIME
Post 10 Jan 2007, 03:38
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. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.