This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: [PATCH] X86: Add pseudo prefixes to control encoding
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 07 Nov 2016 01:31:48 -0700
- Subject: Re: RFC: [PATCH] X86: Add pseudo prefixes to control encoding
- Authentication-results: sourceware.org; auth=none
- References: <20161104182417.GA31915@intel.com>
>>> On 04.11.16 at 19:24, <hongjiu.lu@intel.com> 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.
And then there are mnemonics which have two alternate base
opcodes (e.g. {,v}movq and {,v}pextrw). I think this prefix model
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