[PATCH 06/10] x86: improve handling of insns with ambiguous operand sizes

Jan Beulich jbeulich@suse.com
Mon Aug 12 08:21:00 GMT 2019

On 10.08.2019 01:10,  H.J. Lu  wrote:
>  From assembly program and debug perspective, a suffix is very useful
> when there may be different memory operand sizes.   Allowing more
> cases without suffix isn't helping here.  We need a strong reason to
> do that.

I've given this very simple and (imo) pretty strong reason:
Consistency. Programmers ought to be able to deduce from observed
behavior on one insn how another, similar insns is going to be
treated by the assembler. Once again, simply compare un-patched
gas behavior for

	add	$1, (%eax)
	bt	$1, (%eax)


	add	$0x89, (%eax)
	shl	$1, (%eax)
	shl	$2, (%eax)
	shl	%cl, (%eax)

This is simply unacceptable.

Having put together this series I think I've managed to (mostly)
understand why this is, but the pattern behind it has absolutely
nothing to do with how programmers should write their code.

I wouldn't, btw., mind if we uniformly rejected ambiguous insns,
but it was my understanding from the original discussion (a few
years back) that you wouldn't accept this.

In any event, may I remind you that during said earlier discussion
you had agreed to the underlying concept, including setting forth
acceptance criteria? I view it as entirely unreasonable that
you've made me invest quite a bit of time to fulfill those
criteria (and to get the patch, which as you can see has ended up
as a series) into a shape where the result is actually making
sense, just to find now that all of the sudden you mean to block
all of this work.


More information about the Binutils mailing list