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: 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


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