This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: [PATCH] X86: Add pseudo prefixes to control encoding

>>> On 07.11.16 at 23:26, <> wrote:
> On Mon, Nov 7, 2016 at 12:31 AM, Jan Beulich <> wrote:
>>>>> On 04.11.16 at 19:24, <> wrote:
>>> Many x86 instructions have more than one encodings.  Assembler picks
>>> the default one, usually the shortest one.  Although the ".s", ".d8"
>>> and ".d32" suffixes can be used to swap register operands or specify
>>> displacement size, they aren't very flexible.  This patch adds pseudo
>>> prefixes, {xxx}, to control instruction encoding.  The available
>>> pseudo prefixes are {disp8}, {disp32}, {swap}, {vex2}, {vex3} and
>>> {evex}.  Pseudo prefixes are preferred over the ".s", ".d8" and ".d32"
>>> suffixes, which are deprecated.
>>> Any comments?
>> Looking at ...
>>> --- /dev/null
>>> +++ b/gas/testsuite/gas/i386/pseudos.s
>>> @@ -0,0 +1,52 @@
>>> +# Check instructions with pseudo prefixes for encoding
>>> +
>>> +     .text
>>> +_start:
>>> +     {vex3} vmovaps %xmm7,%xmm2
>>> +     {vex3} {swap} vmovaps %xmm7,%xmm2
>>> +     vmovaps %xmm7,%xmm2
>>> +     {vex2} vmovaps %xmm7,%xmm2
>>> +     {vex2} {swap} vmovaps %xmm7,%xmm2
>>> +     mov %ecx, %eax
>>> +     {swap} mov %ecx, %eax
>> ... all of these, I think {swap} is a bad name, as it implies that there
>> is a particular encoding that the assembler chooses now and
>> forever. That, however, should be an implementation detail, and
>> hence the prefix should express exactly which encoding is wanted.
>> Sadly I can't think of a really concise short name for them; {rm-reg}
>> and {reg-rm} look a little ugly to me, namely due to the embedded
>> dash.
> For most parts, programmer isn't aware how operands are encoded.
> {swap} tells assembler to swap register operand order in encoding.
> Since Intel and AT&T have different operand order, {rm-reg} may be
> confusing.

I can accept the "confusing" part, but I'm missing some alternative
suggestion. If you want the programmer to be able to control the
encoding, then it only makes sense if you give him/her full control.
That is either there's no prefix (in which case the assembler gets to
choose) or there is a prefix (in which case the encoding is full
controlled by the prefix). IOW a single prefix will not do.

>> And then there are mnemonics which have two alternate base
>> opcodes (e.g. {,v}movq and {,v}pextrw). I think this prefix model
> vmovq %rax, %xmm
> isn't equivalent to
> movq %rax, %xmm
> since only VEX encoding clear the upper bits.

And I didn't say they would be. Instead I did refer to the two
different base opcodes (660FD6 and F30F7E vs 660F6E and
660F7E when talking about transfer between XMM register
and memory [different opcodes apply for MM registers] and
660FC5 vs 660F3A15 when talking about PEXTRW with a
GPR destination). Equivalent considerations apply for the
VEX and EVEX encoded forms. I didn't do a very careful check
whether there are any further redundant encodings.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]