ia32 suffix inconsistency

[Jan Beulich]

>>> On 15.12.10 at 17:40, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> On Wed, Dec 15, 2010 at 8:25 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>> On 15.12.10 at 16:08, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>> On Wed, Dec 15, 2010 at 3:11 AM, Etienne Lorrain
>>> <etienne_lorrain@yahoo.fr> wrote:
>>>> Hello,
>>>>
>>>> Just a small detail I think I have to report, with:
>>>> GNU assembler (GNU Binutils for Debian) 2.20.1-system.20100303
>>>> This assembler was configured for a target of `i486-linux-gnu'
>>>> It is not a regression, i.e. same behaviour for years.
>>>>
>>>> We have to postfix 'l' (or 'w' or 'b') when using a simple 'mov' or 'test':
>>>> $ echo 'mov $1,(%ebx)' | as
>>>> {standard input}: Assembler messages:
>>>> {standard input}:1: Error: no instruction mnemonic suffix given and no
>>> register operands; can't size instruction
>>>> $ echo 'movl $1,(%ebx)' | as
>>>> $ echo 'test $1,(%ebx)' | as
>>>> {standard input}: Assembler messages:
>>>> {standard input}:1: Error: no instruction mnemonic suffix given and no
>>> register operands; can't size instruction
>>>> $
>>>
>>> Those insns don't extend immX to 32bit/64bit.
>>>
>>>> but other instructions like and/cmp/xor/or should also need such suffix,
>>> isn't it?
>>>> $ echo 'and $1,(%ebx)' | as
>>>> $ echo 'cmp $1,(%ebx)' | as
>>>> $ echo 'xor $1,(%ebx)' | as
>>>> $ echo 'or $1,(%ebx)' | as
>>>
>>> Those insns extend immX to 32bit first.
>>
>> But whether an extension of the immediate happens shouldn't
>> matter for diagnostics to be generated: It is as bogus to write
>>
>>        mov     $1, (%eax)
>>
>> as it is for
>>
>>        add     $1, (%eax)
>>
>> yet in one case the assembler *guesses* what the programmer
>> meant whereas in the other case it errors out.
>>
> 
> AT&T assembly defaults to 32bit.  If there is no ambiguity in
> operation, gas won't complain.

I don't follow: In what way is the "add" case above more
ambiguous than the "mov" one? Both could mean byte, word,
or dword accesses. And for the "add" case, if the default
indeed is meant ot be 32-bits, there's *no* ambiguity wrt
the width of the immediate (as with "addl", one can clearly
expect the smaller to be picked as long as the immediate fits).

Jan