public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@bigpond.net.au>
To: "H. J. Lu" <hjl@lucon.org>
Cc: "Allan B. Cruse" <cruse@cs.usfca.edu>,
	binutils@sources.redhat.com, gcc@gcc.gnu.org,
	libc-alpha@sources.redhat.com, linux-kernel@vger.kernel.org
Subject: Re: Change i386 assembler/disassembler for SIB with INDEX==4
Date: Fri, 14 Jan 2005 00:18:00 -0000	[thread overview]
Message-ID: <20050114001735.GB3408@bubble.modra.org> (raw)
In-Reply-To: <20050113224601.GA3184@lucon.org>

On Thu, Jan 13, 2005 at 02:46:01PM -0800, H. J. Lu wrote:
> On Thu, Jan 13, 2005 at 12:33:28PM -0800, Allan B. Cruse wrote:
> > 
> > On Thu, 13 Jan 2005, "H. J. Lu" <hjl@lucon.org> wrote:
> > >
> > >
> > >
> > > Subject: Change i386 assembler/disassembler for SIB with INDEX==4
> > > 
> > > I am proposing to change i386 assembler/disassembler for SIB with
> > > INDEX==4
> > >                                                                                
> > > http://sources.redhat.com/bugzilla/show_bug.cgi?id=658
> > >                                                                                
> > > It will change the assembler output for (%ebx,[1248]). I am not too
> > > worried about the disassembler output since assembler can't generate
> > > SIB with INDEX==4 directly today. Any comments?
> > > 
> > > 
> > > H.J.
> > > 
> > 
> > 
> > This change would give programmers the freedom to write instruction-
> > syntax that the processor cannot actually execute, is that right?  
> 
> No. Assemberl will turn "mov (%ebx,2),%eax" into "8b 04 63", which
> is valid i386 machine code.

I don't see any particular need to support generation of this
instruction coding.  Feeding the output of the disassembler back to the
assembler won't generate the same encodings for many instructions, eg.
there are two ways to encode mov %eax,%ebx (and some people even use
the two reg->reg move encodings to hide messages in code).  Another
example is that the assembler chooses the smallest immediate or
displacement encoding.

> > 
> > Perhaps the downside to this would lie in the hours of debugging and
> > private research each programmer would then be faced with, trying to
> > figure out why  " movl (%esi,2),%eax "  wasn't doing what he/she had
> > intended, and which the assembler had dutifully accepted.    --ABC

Huh?  The assembler will warn about this construct, and we certainly
should continue to warn, so that people who meant to write
"mov (,%esi,2),%eax" get a clue.

> 
> What do you expect "movl (%esi,2),%eax" will do?
> 
> 
> H.J.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

  reply	other threads:[~2005-01-14  0:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-13 20:33 Allan B. Cruse
2005-01-13 22:48 ` H. J. Lu
2005-01-14  0:18   ` Alan Modra [this message]
2005-01-14  0:32     ` Thorsten Glaser
  -- strict thread matches above, loose matches on Subject: below --
2005-01-13 19:35 H. J. Lu
2005-01-14  0:22 ` Thorsten Glaser
2005-01-14  0:38   ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050114001735.GB3408@bubble.modra.org \
    --to=amodra@bigpond.net.au \
    --cc=binutils@sources.redhat.com \
    --cc=cruse@cs.usfca.edu \
    --cc=gcc@gcc.gnu.org \
    --cc=hjl@lucon.org \
    --cc=libc-alpha@sources.redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).