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


On Mon, Aug 12, 2019 at 1:21 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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)
>
> vs
>
>         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.

My concerns are

1. AT&T syntax uses suffix for memory operand size.
2. Many instructions without suffix are accepted with default memory
size.
3. Default memory size isn't consistent.
4. Programmers have lived with inconsistency for years.

I'd like to require suffix when memory sizes are possible.  It certainly
won't happen.  But adding more default memory size doesn't help
AT&T syntax.

-- 
H.J.


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