This is the mail archive of the binutils@sourceware.org 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: x86: AT&T syntax operand size defaults


On Wed, Nov 15, 2017 at 2:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 16.10.17 at 13:24, <hjl.tools@gmail.com> wrote:
>> On Mon, Oct 16, 2017 at 3:09 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 13.10.17 at 23:51, <hjl.tools@gmail.com> wrote:
>>>> 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.
>
> So there's one first fundamental roadblock here: Quite a few FPU
> insns specify Dword|Qword|Unspecified. It seems rather obvious to me
> that this can't be right (Unspecified should only be used when only a
> single operand size is permitted), but even the disassembler doesn't
> add an 's' suffix for at least the integer form ones. Would you agree
> with fixing the disassembler independently of that other work?
>

Will this require change assembler testcase inputs?  Will the disassmebler
output match the input?


-- 
H.J.


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