Change i386 assembler/disassembler for SIB with INDEX==4

Change i386 assembler/disassembler for SIB with INDEX==4

[H. J. Lu]

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.

Re: Change i386 assembler/disassembler for SIB with INDEX==4

[Thorsten Glaser]

(Removing GNU/Linux groups from the output)

H. J. Lu dixit:

>I am proposing to change i386 assembler/disassembler for SIB with
>INDEX==4
>
>http://sources.redhat.com/bugzilla/show_bug.cgi?id=658

The intel output looks even more weird, is this a shortcoming
in the assembler?

(Use -M intel, not -m i386:intel, the latter gave me 64 bit output!)

tg@odem:/home/tg $ objdump -d -M intel x.o

x.o:     file format elf32-i386

Disassembly of section .text:

00000000 <.text>:
   0:   8b 04 23                mov    eax,DWORD PTR [ebx]
   3:   8b 04 63                mov    eax,DWORD PTR [ebx*2]
   6:   8b 04 a3                mov    eax,DWORD PTR [ebx*4]
   9:   8b 04 e3                mov    eax,DWORD PTR [ebx*8]
tg@odem:/home/tg $ cat >y.s
.intel_syntax noprefix
mov    eax,DWORD PTR [ebx]
mov    eax,DWORD PTR [ebx*2]
mov    eax,DWORD PTR [ebx*4]
mov    eax,DWORD PTR [ebx*8]
tg@odem:/home/tg $ gcc -c y.s
tg@odem:/home/tg $ objdump -d y.o

y.o:     file format elf32-i386

Disassembly of section .text:

00000000 <.text>:
   0:   8b 03                   mov    (%ebx),%eax
   2:   8b 04 5d 00 00 00 00    mov    0x0(,%ebx,2),%eax
   9:   8b 04 9d 00 00 00 00    mov    0x0(,%ebx,4),%eax
  10:   8b 04 dd 00 00 00 00    mov    0x0(,%ebx,8),%eax
tg@odem:/home/tg $ objdump -d -M intel y.o

y.o:     file format elf32-i386

Disassembly of section .text:

00000000 <.text>:
   0:   8b 03                   mov    eax,DWORD PTR [ebx]
   2:   8b 04 5d 00 00 00 00    mov    eax,DWORD PTR [ebx*2]
   9:   8b 04 9d 00 00 00 00    mov    eax,DWORD PTR [ebx*4]
  10:   8b 04 dd 00 00 00 00    mov    eax,DWORD PTR [ebx*8]

//mirabile

Re: Change i386 assembler/disassembler for SIB with INDEX==4

[Alan Modra]

On Fri, Jan 14, 2005 at 12:14:53AM +0000, Thorsten Glaser wrote:
> The intel output looks even more weird, is this a shortcoming
> in the assembler?

Yes, that's plainly a bug, since the disassembled code is specifying
ebx as an index register, not a base register.  ie. In intel mode
we should be showing

   0:   8b 04 23                mov    eax,DWORD PTR [ebx+0*1]
   3:   8b 04 63                mov    eax,DWORD PTR [ebx+0*2]
   6:   8b 04 a3                mov    eax,DWORD PTR [ebx+0*4]
   9:   8b 04 e3                mov    eax,DWORD PTR [ebx+0*8]

or something like that.

> (Use -M intel, not -m i386:intel, the latter gave me 64 bit output!)
> 
> tg@odem:/home/tg $ objdump -d -M intel x.o
> 
> x.o:     file format elf32-i386
> 
> Disassembly of section .text:
> 
> 00000000 <.text>:
>    0:   8b 04 23                mov    eax,DWORD PTR [ebx]
>    3:   8b 04 63                mov    eax,DWORD PTR [ebx*2]
>    6:   8b 04 a3                mov    eax,DWORD PTR [ebx*4]
>    9:   8b 04 e3                mov    eax,DWORD PTR [ebx*8]

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Change i386 assembler/disassembler for SIB with INDEX==4

[Allan B. Cruse]

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?  

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

Re: Change i386 assembler/disassembler for SIB with INDEX==4

[H. J. Lu]

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.

> 
> 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
> 

What do you expect "movl (%esi,2),%eax" will do?


H.J.

Re: Change i386 assembler/disassembler for SIB with INDEX==4

[Alan Modra]

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

Re: Change i386 assembler/disassembler for SIB with INDEX==4

[Thorsten Glaser]

Alan Modra dixit:

>Another
>example is that the assembler chooses the smallest immediate or
>displacement encoding.

Apparently it's not always so smart, look at my other posting.

bye,
//mirabile