This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Behaviour of i386 add instruction changes based on operand
"Jan Beulich" <jbeulich@novell.com> writes:
> >>> Ian Lance Taylor <iant@google.com> 07.12.06 22:44 >>>
> >Assemble this i386 source:
> >
> > add $1, 0(%edx)
> > add $128, 0(%edx)
> >
> >I get this:
> >
> >foo.s: Assembler messages:
> >foo.s:2: Error: no instruction mnemonic suffix given and no register operands; can't size instruction
> >
> >The instructions do generate different opcodes (0x80 vs. 0x83). When
> >adding a constant to memory, if the operand is a sign extended 8-bit
> >value, we default to addl. If the operand is something else, we have
> >no default. That seems inconsistent. Is this a bug or a feature?
>
> Half and half - the opcode selection I guess is meant to be a feature (as
> it's really clear that in the first case the shorter instruction can be used),
> but the defaulting to addl (or better, to the default operand size) I always
> considered a bug, where at least a warning should be given. Quite a while
> ago I actually made this an error in Intel mode, but I refrained from doing
> so for AT&T due to the vague status of that code (given there's no official
> specification for this).
I understand the concern about changing AT&T mode. Still, I think the
current situation, in which add constant to memory becomes addl for a
signed 8-bit value and generates an error for any other value, can not
be considered to be correct.
Does anybody think that we should not change
add $1, 0(%edx)
to generate a "can't size instruction" error?
As far as I can gcc will always generate a size suffix in AT&T mode.
Ian