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: ia32 suffix inconsistency


On Wed, Dec 15, 2010 at 8:50 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>> 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).
>

I don't see any problems:


[hjl@gnu-35 tmp]$ cat x.s
 mov     $1, (%eax)
[hjl@gnu-35 tmp]$ cat y.s
 add     $1, (%eax)
[hjl@gnu-35 tmp]$ cat x.s
 mov     $1, (%eax)
[hjl@gnu-35 tmp]$ gcc -c -m32 x.s
x.s: Assembler messages:
x.s:1: Error: no instruction mnemonic suffix given and no register
operands; can't size instruction
[hjl@gnu-35 tmp]$ cat y.s
 add     $1, (%eax)
[hjl@gnu-35 tmp]$ gcc -c -m32 y.s
[hjl@gnu-35 tmp]$ objdump -dw y.o

y.o:     file format elf32-i386


Disassembly of section .text:

00000000 <.text>:
   0:	83 00 01             	addl   $0x1,(%eax)
[hjl@gnu-35 tmp]$


-- 
H.J.


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