[PATCH 06/10] x86: improve handling of insns with ambiguous operand sizes
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