Index
> Compiler Internals > Bug with movsxd |
| Author |
|
|
revolution 06 Jan 2007, 11:31
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. Seems to me to be a philosophical thing, should fasm support 'MOVSXD r32,r32', disallow it (the current behaviour) or change it to MOV? |
|||
06 Jan 2007, 11:31 |
|
|
Tomasz Grysztar 06 Jan 2007, 11:50
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.
|
|||
|
06 Jan 2007, 11:50 |
|
|
MazeGen 07 Jan 2007, 17:34
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.
|
|||
|
07 Jan 2007, 17:34 |
|
|
Tomasz Grysztar 07 Jan 2007, 23:05
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).
|
|||
|
07 Jan 2007, 23:05 |
|
|
kohlrak 08 Jan 2007, 05:24
Essentually, think of his implimentation as assembler level optimization.
|
|||
|
08 Jan 2007, 05:24 |
|
|
MazeGen 08 Jan 2007, 13:13
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  |
|||
|
08 Jan 2007, 13:13 |
|
|
Tomasz Grysztar 08 Jan 2007, 16:09
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. |
|||
|
08 Jan 2007, 16:09 |
|
|
Xorpd! 10 Jan 2007, 03:38
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 |
|||
|
10 Jan 2007, 03:38 |
|
< Last Thread | Next Thread > |
Forum Rules:
|