This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: x86: AT&T syntax operand size defaults
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Beulich <JBeulich at suse dot com>
- Cc: binutils at sourceware dot org
- Date: Fri, 13 Oct 2017 14:51:56 -0700
- Subject: Re: x86: AT&T syntax operand size defaults
- Authentication-results: sourceware.org; auth=none
- References: <59E0DF6F02000078001863F4@prv-mh.provo.novell.com>
On 10/13/17, Jan Beulich <JBeulich@suse.com> wrote:
> All,
>
> according to the only reasonable document about AT&T assembler
> syntax (Solaris'es / Oracles "x86 Assembly Language Reference
> Manual", operand size is supposed to default to "long".
>
> However, of these two
>
> add $1, (%eax)
> add $0x1234, (%eax)
>
> the first indeed defaults to "long" (except in 16-bit mode, but I think
> that's fine despite what that doc says) while the second causes an
> error. That's because of
>
> if (i.tm.opcode_modifier.w)
> {
> as_bad (_("no instruction mnemonic suffix given and "
> "no register operands; can't size instruction"));
> return 0;
> }
>
> in process_suffix(): The pattern for the 8-bit sign extended
> immediate does no have W set, while most other instructions
> allowing for no register operands at all have it set. I'm of the
> strong opinion that the behavior of the assembler should at least
> be consistent, i.e. in particular it should not depend on the value
> of an immediate.
>
> Which way to make it consistent, though, I'm not sure about:
> It could be made match Intel syntax behavior, where an error is
> being flagged whenever multiple operand sizes are permitted for
> a mnemonic (that's imo the model most helpful to the programmer),
> or it could be made match that doc by simply removing the as_bad()
> invocation above (which is the model accepting the widest set of
> originally non-gas sources). Of course it would be possible to have
> the user select between the two by command line option and/or
> directive, but even then we would need to settle on what default
> behavior should be.
>
I agreed that AT&T syntax is poorly documented. As for this specific
case, I am OK with either option as long as it doesn't break existing
codes.
--
H.J.