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 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

> 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.

Pseudo prefixes provide encoding choice which otherwise isn't
available.  There is no need to add a pseudo prefix to encode
movq as vmovq.

> should cover them too, albeit I have even more of a problem
> thinking of some good naming of the needed prefix(es), the more
> that ideally this would allow for potential future extension to cope
> with three or more different encodings for a single mnemonic.
> Jan


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