This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Feature request: Set the direction flag on x86/x64 register->register operations
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Jan Beulich" <jbeulich at novell dot com>
- Cc: stefan at codeweavers dot com, binutils at sourceware dot org
- Date: Mon, 22 Dec 2008 07:47:45 -0800
- Subject: Re: Feature request: Set the direction flag on x86/x64 register->register operations
- References: <494F51B7.76E4.0078.0@novell.com>
On Sun, Dec 21, 2008 at 11:37 PM, Jan Beulich <jbeulich@novell.com> wrote:
>>>> "H.J. Lu" <hjl.tools@gmail.com> 19.12.08 16:54 >>>
>>On Fri, Dec 19, 2008 at 7:40 AM, Jan Beulich <jbeulich@novell.com> wrote:
>>>>>> "H.J. Lu" <hjl.tools@gmail.com> 19.12.08 16:25 >>>
>>>>On Fri, Dec 19, 2008 at 1:07 AM, Jan Beulich <jbeulich@novell.com> wrote:
>>>>> Also, the whole thing seems half-baked to me, as it only deals with
>>>>> alternative encodings using the 'D' bit. Using an .a suffix and handling
>>>>
>>>>".r" handles insns which can be encoded differently by swapping operands
>>>>in encoding:
>>>
>>> But I was thinking of movq (between mm or xmm registers), pextrw, or
>>
>>I will add movq/movd. pextrx doesn't involve swap operand. It is
>>just a new encoding.
>>
>>> 64-bit mov between mm/xmm and memory in 64-bit mode.
>>>
>>
>>You can't swap operands in encoding when moving between
>>reg and memory.
>
> Btw., in an entirely different context I noticed that this operand swapping
> may be desirable elsewhere: vmovq and vmovss (perhaps other?) in some
> case currently use the longer encoding starting with opcode 0xc4 on
> x86-64 when, by using the alternative base opcode, the short 0xc5-based
> encoding could be used - just look at the disassembly of this fragment:
>
> .intel_syntax noprefix
> .text
> .code64
> Start64:
> vmovq xmm15, xmm0
> vmovq xmm0, xmm15
> .byte 0xc5, 0x79, 0xd6, 0xf8 # vmovq xmm0, xmm15
>
> vmovss xmm15, xmm0, xmm0
> vmovss xmm0, xmm15, xmm0
> vmovss xmm0, xmm0, xmm15
> .byte 0xc5, 0x7a, 0x11, 0xf8 # vmovss xmm0, xmm0, xmm15
>
> As the assembler generally uses the shortest possible encoding, it should
> do so in these cases too, I would think.
>
I think it is due to the W bit. I will see what I can do.
--
H.J.