Re: Behaviour of i386 add instruction changes based on operand

["H. J. Lu" <hjl at lucon dot org>]

On Fri, Dec 08, 2006 at 06:20:44PM -0800, Ian Lance Taylor wrote:
> "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?
> 

I don't have an objection if Linux kernel and glibc compile OK.


H.J.