[PATCH] x86: suppress emission of zero displacements in memory operands

[PATCH] x86: suppress emission of zero displacements in memory operands

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 4329 bytes --]

When explicitly specified, gas encoded a pointless zero displacement in
memory addressing forms. Since this is not normally desired and was most
likely just an oversight, this patch adds an adjustment to eliminate the
displacement in that case.

Built and tested on i686-pc-linux-gnu and x86_64-unknown-linux-gnu.

Jan

gas/
2005-05-06  Jan Beulich  <jbeulich@novell.com>

	* config/tc-i386.c (optimize_disp): Discard displacement entirely when zero and
	not required by encoding constraints.

gas/testsuite/
2005-05-06  Jan Beulich  <jbeulich@novell.com>

	* gas/i386/tlsd.[sd]: Adjust to not assume zero displacement will
	actually be present in memory addressing.
	* gas/i386/tlspic.[sd]: Likewise.

--- /home/jbeulich/src/binutils/mainline/2005-05-06/gas/config/tc-i386.c	2005-05-06 08:24:28.000000000 +0200
+++ 2005-05-06/gas/config/tc-i386.c	2005-05-06 11:45:55.861726528 +0200
@@ -2069,7 +2082,13 @@ optimize_disp ()
 	    disp &= (((offsetT) 2 << 31) - 1);
 	    disp = (disp ^ ((offsetT) 1 << 31)) - ((addressT) 1 << 31);
 	  }
-	if (flag_code == CODE_64BIT)
+	if (!disp && (i.types[op] & BaseIndex))
+	  {
+	    i.types[op] &= ~Disp;
+	    i.op[op].disps = 0;
+	    i.disp_operands--;
+	  }
+	else if (flag_code == CODE_64BIT)
 	  {
 	    if (fits_in_signed_long (disp))
 	      i.types[op] |= Disp32S;
--- /home/jbeulich/src/binutils/mainline/2005-05-06/gas/testsuite/gas/i386/tlsd.d	2002-05-23 15:12:50.000000000 +0200
+++ 2005-05-06/gas/testsuite/gas/i386/tlsd.d	2005-05-06 11:01:48.000000000 +0200
@@ -22,10 +22,10 @@ Disassembly of section .text:
 [ 	]+1f: R_386_TLS_LDM	bar
   23:	e8 fc ff ff ff [ 	]*call   24 <fn\+0x24>
 [ 	]+24: R_386_PLT32	___tls_get_addr
-  28:	8d 7f 00 [ 	]*lea    0x0\(%edi\),%edi
+  28:	83 c7 00 [ 	]*add    \$0x0,%edi
   2b:	8d 90 00 00 00 00 [ 	]*lea    0x0\(%eax\),%edx
 [ 	]+2d: R_386_TLS_LDO_32	bar
-  31:	8d 76 00 [ 	]*lea    0x0\(%esi\),%esi
+  31:	83 c6 00 [ 	]*add    \$0x0,%esi
   34:	8d 88 00 00 00 00 [ 	]*lea    0x0\(%eax\),%ecx
 [ 	]+36: R_386_TLS_LDO_32	baz
   3a:	8b 5d fc [ 	]*mov    0xfffffffc\(%ebp\),%ebx
--- /home/jbeulich/src/binutils/mainline/2005-05-06/gas/testsuite/gas/i386/tlsd.s	2002-05-23 15:12:50.000000000 +0200
+++ 2005-05-06/gas/testsuite/gas/i386/tlsd.s	2005-05-06 11:03:36.000000000 +0200
@@ -26,13 +26,13 @@ fn:
 	call	___tls_get_addr@PLT
 
 	/* Just show that there can be arbitrary instructions here  */
-	leal	0(%edi, 1), %edi
+	addl	$0, %edi
 
 	leal	bar@DTPOFF(%eax), %edx
 	/* %edx now contains &bar  */
 
 	/* Again, arbitrary instructions  */
-	leal	0(%esi, 1), %esi
+	addl	$0, %esi
 
 	leal	baz@DTPOFF(%eax), %ecx
 	/* %ecx now contains &baz  */
--- /home/jbeulich/src/binutils/mainline/2005-05-06/gas/testsuite/gas/i386/tlspic.d	2002-09-19 21:01:13.000000000 +0200
+++ 2005-05-06/gas/testsuite/gas/i386/tlspic.d	2005-05-06 11:04:11.000000000 +0200
@@ -1,5 +1,5 @@
 #objdump: -dr
-#name: i386 non-pic tls
+#name: i386 pic tls
 
 .*: +file format .*
 
@@ -15,12 +15,12 @@ Disassembly of section .text:
    b:	81 c3 03 00 00 00 [ 	]*add    \$0x3,%ebx
 [ 	]+d: R_386_GOTPC	_GLOBAL_OFFSET_TABLE_
   11:	65 a1 00 00 00 00 [ 	]*mov    %gs:0x0,%eax
-  17:	8d 76 00 [ 	]*lea    0x0\(%esi\),%esi
+  17:	83 c6 00 [ 	]*add    \$0x0,%esi
   1a:	2b 83 00 00 00 00 [ 	]*sub    0x0\(%ebx\),%eax
 [ 	]+1c: R_386_TLS_IE_32	foo
   20:	8b 83 00 00 00 00 [ 	]*mov    0x0\(%ebx\),%eax
 [ 	]+22: R_386_TLS_GOTIE	foo
-  26:	8d 76 00 [ 	]*lea    0x0\(%esi\),%esi
+  26:	83 c6 00 [ 	]*add    \$0x0,%esi
   29:	65 8b 00 [ 	]*mov    %gs:\(%eax\),%eax
   2c:	65 8b 0d 00 00 00 00 [ 	]*mov    %gs:0x0,%ecx
   33:	03 8b 00 00 00 00 [ 	]*add    0x0\(%ebx\),%ecx
--- /home/jbeulich/src/binutils/mainline/2005-05-06/gas/testsuite/gas/i386/tlspic.s	2002-09-19 21:01:13.000000000 +0200
+++ 2005-05-06/gas/testsuite/gas/i386/tlspic.s	2005-05-06 11:03:48.000000000 +0200
@@ -17,7 +17,7 @@ fn:
 	movl	%gs:0, %eax
 
 	/* Arbitrary instructions in between.  */
-	leal	0(%esi, 1), %esi
+	addl	$0, %esi
 
 	subl	foo@GOTTPOFF(%ebx), %eax
 	/* %eax now contains &foo  */
@@ -26,7 +26,7 @@ fn:
 	movl	foo@GOTNTPOFF(%ebx), %eax
 
 	/* Arbitrary instructions in between.  */
-	leal	0(%esi, 1), %esi
+	addl	$0, %esi
 
 	movl	%gs:(%eax), %eax
 	/* %eax now contains foo  */


[-- Attachment #2: binutils-mainline-x86-zero-mem-disp.patch --]
[-- Type: text/plain, Size: 4211 bytes --]

When explicitly specified, gas encoded a pointless zero displacement in
memory addressing forms. Since this is not normally desired and was most
likely just an oversight, this patch adds an adjustment to eliminate the
displacement in that case.

Built and tested on i686-pc-linux-gnu and x86_64-unknown-linux-gnu.

Jan

gas/
2005-05-06  Jan Beulich  <jbeulich@novell.com>

	* config/tc-i386.c (optimize_disp): Discard displacement entirely when zero and
	not required by encoding constraints.

gas/testsuite/
2005-05-06  Jan Beulich  <jbeulich@novell.com>

	* gas/i386/tlsd.[sd]: Adjust to not assume zero displacement will
	actually be present in memory addressing.
	* gas/i386/tlspic.[sd]: Likewise.

--- /home/jbeulich/src/binutils/mainline/2005-05-06/gas/config/tc-i386.c	2005-05-06 08:24:28.000000000 +0200
+++ 2005-05-06/gas/config/tc-i386.c	2005-05-06 11:45:55.861726528 +0200
@@ -2069,7 +2082,13 @@ optimize_disp ()
 	    disp &= (((offsetT) 2 << 31) - 1);
 	    disp = (disp ^ ((offsetT) 1 << 31)) - ((addressT) 1 << 31);
 	  }
-	if (flag_code == CODE_64BIT)
+	if (!disp && (i.types[op] & BaseIndex))
+	  {
+	    i.types[op] &= ~Disp;
+	    i.op[op].disps = 0;
+	    i.disp_operands--;
+	  }
+	else if (flag_code == CODE_64BIT)
 	  {
 	    if (fits_in_signed_long (disp))
 	      i.types[op] |= Disp32S;
--- /home/jbeulich/src/binutils/mainline/2005-05-06/gas/testsuite/gas/i386/tlsd.d	2002-05-23 15:12:50.000000000 +0200
+++ 2005-05-06/gas/testsuite/gas/i386/tlsd.d	2005-05-06 11:01:48.000000000 +0200
@@ -22,10 +22,10 @@ Disassembly of section .text:
 [ 	]+1f: R_386_TLS_LDM	bar
   23:	e8 fc ff ff ff [ 	]*call   24 <fn\+0x24>
 [ 	]+24: R_386_PLT32	___tls_get_addr
-  28:	8d 7f 00 [ 	]*lea    0x0\(%edi\),%edi
+  28:	83 c7 00 [ 	]*add    \$0x0,%edi
   2b:	8d 90 00 00 00 00 [ 	]*lea    0x0\(%eax\),%edx
 [ 	]+2d: R_386_TLS_LDO_32	bar
-  31:	8d 76 00 [ 	]*lea    0x0\(%esi\),%esi
+  31:	83 c6 00 [ 	]*add    \$0x0,%esi
   34:	8d 88 00 00 00 00 [ 	]*lea    0x0\(%eax\),%ecx
 [ 	]+36: R_386_TLS_LDO_32	baz
   3a:	8b 5d fc [ 	]*mov    0xfffffffc\(%ebp\),%ebx
--- /home/jbeulich/src/binutils/mainline/2005-05-06/gas/testsuite/gas/i386/tlsd.s	2002-05-23 15:12:50.000000000 +0200
+++ 2005-05-06/gas/testsuite/gas/i386/tlsd.s	2005-05-06 11:03:36.000000000 +0200
@@ -26,13 +26,13 @@ fn:
 	call	___tls_get_addr@PLT
 
 	/* Just show that there can be arbitrary instructions here  */
-	leal	0(%edi, 1), %edi
+	addl	$0, %edi
 
 	leal	bar@DTPOFF(%eax), %edx
 	/* %edx now contains &bar  */
 
 	/* Again, arbitrary instructions  */
-	leal	0(%esi, 1), %esi
+	addl	$0, %esi
 
 	leal	baz@DTPOFF(%eax), %ecx
 	/* %ecx now contains &baz  */
--- /home/jbeulich/src/binutils/mainline/2005-05-06/gas/testsuite/gas/i386/tlspic.d	2002-09-19 21:01:13.000000000 +0200
+++ 2005-05-06/gas/testsuite/gas/i386/tlspic.d	2005-05-06 11:04:11.000000000 +0200
@@ -1,5 +1,5 @@
 #objdump: -dr
-#name: i386 non-pic tls
+#name: i386 pic tls
 
 .*: +file format .*
 
@@ -15,12 +15,12 @@ Disassembly of section .text:
    b:	81 c3 03 00 00 00 [ 	]*add    \$0x3,%ebx
 [ 	]+d: R_386_GOTPC	_GLOBAL_OFFSET_TABLE_
   11:	65 a1 00 00 00 00 [ 	]*mov    %gs:0x0,%eax
-  17:	8d 76 00 [ 	]*lea    0x0\(%esi\),%esi
+  17:	83 c6 00 [ 	]*add    \$0x0,%esi
   1a:	2b 83 00 00 00 00 [ 	]*sub    0x0\(%ebx\),%eax
 [ 	]+1c: R_386_TLS_IE_32	foo
   20:	8b 83 00 00 00 00 [ 	]*mov    0x0\(%ebx\),%eax
 [ 	]+22: R_386_TLS_GOTIE	foo
-  26:	8d 76 00 [ 	]*lea    0x0\(%esi\),%esi
+  26:	83 c6 00 [ 	]*add    \$0x0,%esi
   29:	65 8b 00 [ 	]*mov    %gs:\(%eax\),%eax
   2c:	65 8b 0d 00 00 00 00 [ 	]*mov    %gs:0x0,%ecx
   33:	03 8b 00 00 00 00 [ 	]*add    0x0\(%ebx\),%ecx
--- /home/jbeulich/src/binutils/mainline/2005-05-06/gas/testsuite/gas/i386/tlspic.s	2002-09-19 21:01:13.000000000 +0200
+++ 2005-05-06/gas/testsuite/gas/i386/tlspic.s	2005-05-06 11:03:48.000000000 +0200
@@ -17,7 +17,7 @@ fn:
 	movl	%gs:0, %eax
 
 	/* Arbitrary instructions in between.  */
-	leal	0(%esi, 1), %esi
+	addl	$0, %esi
 
 	subl	foo@GOTTPOFF(%ebx), %eax
 	/* %eax now contains &foo  */
@@ -26,7 +26,7 @@ fn:
 	movl	foo@GOTNTPOFF(%ebx), %eax
 
 	/* Arbitrary instructions in between.  */
-	leal	0(%esi, 1), %esi
+	addl	$0, %esi
 
 	movl	%gs:(%eax), %eax
 	/* %eax now contains foo  */

RE: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Dave Korn]

----Original Message----
>From: Jan Beulich
>Sent: 06 May 2005 13:04

> When explicitly specified, gas encoded a pointless zero displacement in
> memory addressing forms. Since this is not normally desired and was most
> likely just an oversight, this patch adds an adjustment to eliminate the
> displacement in that case.

  I'm not sure if I've fully understood the intent of this patch, but I
think you're saying that if someone writes

        mov %eax,0(%edi)

the assembler will emit

   4 0003 8907          mov %eax,(%edi)

and not

   2 0000 894700        mov %eax,0(%edi)

yes?  Nothing the user _explicitly_ specifies should ever be discarded IMO.
What if someone wants to write self-modifying code that stores varying
offsets into that field?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Andreas Schwab]

"Dave Korn" <dave.korn@artimi.com> writes:

>   I'm not sure if I've fully understood the intent of this patch, but I
> think you're saying that if someone writes
>
>         mov %eax,0(%edi)
>
> the assembler will emit
>
>    4 0003 8907          mov %eax,(%edi)
>
> and not
>
>    2 0000 894700        mov %eax,0(%edi)
>
> yes?  Nothing the user _explicitly_ specifies should ever be discarded IMO.

The m68k assembler is doing something similar, also known as relaxing.

$ echo 'move.w 0(%a0),%d0' | m68k-linux-as -
$ m68k-linux-objdump -d

a.out:     file format elf32-m68k

Disassembly of section .text:

00000000 <.text>:
   0:   3010            movew %a0@,%d0

> What if someone wants to write self-modifying code that stores varying
> offsets into that field?

In the m68k assembler you can force a field by adding an explicit size
modifier.

$ echo 'move.w 0.w(%a0),%d0' | m68k-linux-as -
$ m68k-linux-objdump -d

a.out:     file format elf32-m68k

Disassembly of section .text:

00000000 <.text>:
   0:   3028 0000       movew %a0@(0),%d0

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Dave Korn]

----Original Message----
>From: Andreas Schwab
>Sent: 06 May 2005 15:13

> "Dave Korn" <dave.korn@artimi.com> writes:
> 
>>   I'm not sure if I've fully understood the intent of this patch, ...

> The m68k assembler is doing something similar, also known as relaxing.

  Hopefully *only* if you specify --relax on the command line, no?

>> What if someone wants to write self-modifying code that stores varying
>> offsets into that field?
> 
> In the m68k assembler you can force a field by adding an explicit size
> modifier.

  Yes, I understand that; what I'm asking is if this patch of Jan's actually
discards the field *even if* it is explicitly stated, when the offset value
is zero.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[H. J. Lu]

On Fri, May 06, 2005 at 03:20:59PM +0100, Dave Korn wrote:
> ----Original Message----
> >From: Andreas Schwab
> >Sent: 06 May 2005 15:13
> 
> > "Dave Korn" <dave.korn@artimi.com> writes:
> > 
> >>   I'm not sure if I've fully understood the intent of this patch, ...
> 
> > The m68k assembler is doing something similar, also known as relaxing.
> 
>   Hopefully *only* if you specify --relax on the command line, no?
> 
> >> What if someone wants to write self-modifying code that stores varying
> >> offsets into that field?
> > 
> > In the m68k assembler you can force a field by adding an explicit size
> > modifier.
> 
>   Yes, I understand that; what I'm asking is if this patch of Jan's actually
> discards the field *even if* it is explicitly stated, when the offset value
> is zero.
> 

I agree. User may do it on purpose and TLS optimization may depend on
it. The same effect can be done with different instructions on x86.
Assembler shouldn't pick one which it thinks is the best.


H.J.

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Andreas Schwab]

"Dave Korn" <dave.korn@artimi.com> writes:

> ----Original Message----
>>From: Andreas Schwab
>>Sent: 06 May 2005 15:13
>
>> "Dave Korn" <dave.korn@artimi.com> writes:
>> 
>>>   I'm not sure if I've fully understood the intent of this patch, ...
>
>> The m68k assembler is doing something similar, also known as relaxing.
>
>   Hopefully *only* if you specify --relax on the command line, no?

No, it's the default mode of operation, and there is no command line
option to switch it off.  Probably because it is just too useful for hand
written assembler code.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Dave Korn]

----Original Message----
>From: Andreas Schwab
>Sent: 06 May 2005 15:36

> "Dave Korn" <dave.korn@artimi.com> writes:
> 
>> ----Original Message----
>>> From: Andreas Schwab
>>> Sent: 06 May 2005 15:13
>> 
>>> "Dave Korn" <dave.korn@artimi.com> writes:
>>> 
>>>>   I'm not sure if I've fully understood the intent of this patch, ...
>> 
>>> The m68k assembler is doing something similar, also known as relaxing.
>> 
>>   Hopefully *only* if you specify --relax on the command line, no?
> 
> No, it's the default mode of operation, and there is no command line
> option to switch it off.  

  That's very wrong IMO.  There should always be an equivalent of -O0 - a
way of saying "Do exactly what I say and don't try and be smart about it".
I'd regard it as a bug.  When I used to program Amiga, the tools always
regarded shortening branches as an optimisation, and wouldn't do so unless
you explicitly requested it.

>   Probably because it is just too useful for hand
> written assembler code.

  Well, yes, it's vital for the assembler to support branch optimisation,
because the programmer can't know in advance which branches will be in range
or not.  But it's also in the case of hand-coded assembler that the coder is
*most* likely to want to specify an exact instruction sequence, because the
coder knows things about the program that the assembler doesn't, and it
ought to be (at least) possible if not (IMO) the default behaviour.

  Relaxing branches without the "--relax" option violates the 'least
surprise' principle.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Andreas Schwab]

"Dave Korn" <dave.korn@artimi.com> writes:

>   Well, yes, it's vital for the assembler to support branch optimisation,
> because the programmer can't know in advance which branches will be in range
> or not.  But it's also in the case of hand-coded assembler that the coder is
> *most* likely to want to specify an exact instruction sequence,

Most of the time you want optimal assembler code.

> because the coder knows things about the program that the assembler
> doesn't, and it ought to be (at least) possible if not (IMO) the default
> behaviour.

What if the zero is written as `foo - bar', where foo and bar are local
labels surrounding a region that may be empty?  Surely you want to get
optimal assembler code independent of the value of foo - bar.

> Relaxing branches without the "--relax" option violates the 'least
> surprise' principle.

I disagree.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Richard Henderson]

On Fri, May 06, 2005 at 02:56:52PM +0100, Dave Korn wrote:
> Nothing the user _explicitly_ specifies should ever be discarded IMO.
> What if someone wants to write self-modifying code that stores varying
> offsets into that field?

I agree, unfortunately the i386 assembler doesn't have the length
specifiers that the m68k assembler does.  So if you really wanted
to write self-modifying code, you'd have to write 0x12345678 or
some other constant that forces the size encoding you need.


r~

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Clifford T. Matthews]

Howdy,

I'm a little over a year late to the discussion, but it was only
yesterday that I figured out that I was being bitten by a change that
was made in May of 2005.

Syn68k is software (written by Mat Hostetter) that dynamically
translates 68k assembly to x86 assembly.  It doesn't want to invoke a
full-blown assembler as it does its work, so instead, at build time,
it uses gas to compile a whole bunch of templates and figure out the
significance of the bits that get created.

Starting with binutils-2.16.90.0.3, instructions like

    lea 0x0(%eax),%eax

began compiling into the exact same byte sequence as

    lea (%eax),%eax

That change broke Syn68k, because it observed that the byte sequence
for a zero displacement was significantly different from the rest (two
bytes versus three bytes).  In theory, Syn68k should have been able to
construct translation code that understood the difference.  In
reality, it created code that didn't work.  Oops.

I "fixed" Syn68k by putting in special-case code that tells it to
ignore the templates that have 0 displacements.  That happens to work
for our current template set.  A better fix would be to fix the
pattern matching code to be able to deal with this new change, but
there's not sufficient use of Syn68k to justify the effort.

An alternative fix would be to use whatever syntax (or command line
switch) gas would take to allow Syn68k to tell gas that it really
does want a zero displacement rather than no displacement.  However,
AFAICT, there no longer is such a syntax, nor is there a command line
option to suppress the elision.

I do exceedingly small amounts of assembly work these days and when
things don't go my way, I can still hack tools that I have the source
for (well... actually I can hack tools that I don't have the source
for, but that takes even longer).  As such, the lack of syntax or a
command line switch to request a zero displacement doesn't really
matter to me, but on May 6th 2005, DaveK wrote:

   "Nothing the user _explicitly_ specifies should ever be discarded
    IMO.  What if someone wants to write self-modifying code that
    stores varying offsets into that field?"

I largely agree with that sentiment, but with 20/20 hindsight and
standing on his shoulders, perhaps I'd say

    Removing a way for a user to explicitly request something is bad.
    What if someone wants what he requested for some reason that we
    haven't anticipated?

Either way, my experience might be an interesting data point for some
of you.

-- 
Cliff Matthews <ctm@ardi.com>

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[H. J. Lu]

On Fri, Jul 14, 2006 at 11:03:38AM -0600, Clifford T. Matthews wrote:
> Howdy,
> 
> I'm a little over a year late to the discussion, but it was only
> yesterday that I figured out that I was being bitten by a change that
> was made in May of 2005.
> 
> Syn68k is software (written by Mat Hostetter) that dynamically
> translates 68k assembly to x86 assembly.  It doesn't want to invoke a
> full-blown assembler as it does its work, so instead, at build time,
> it uses gas to compile a whole bunch of templates and figure out the
> significance of the bits that get created.
> 
> Starting with binutils-2.16.90.0.3, instructions like
> 
>     lea 0x0(%eax),%eax
> 
> began compiling into the exact same byte sequence as
> 
>     lea (%eax),%eax
> 

I have been thinking to use 0x0B, 0x0W, 0x0L to indicate the size
of displacements.


H.J.

RE: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Dave Korn]

On 14 July 2006 18:31, H. J. Lu wrote:

> On Fri, Jul 14, 2006 at 11:03:38AM -0600, Clifford T. Matthews wrote:
>> Howdy,
>> 
>> I'm a little over a year late to the discussion, but it was only
>> yesterday that I figured out that I was being bitten by a change that was
>> made in May of 2005. 
>> 
>> Syn68k is software (written by Mat Hostetter) that dynamically
>> translates 68k assembly to x86 assembly.  It doesn't want to invoke a
>> full-blown assembler as it does its work, so instead, at build time,
>> it uses gas to compile a whole bunch of templates and figure out the
>> significance of the bits that get created.
>> 
>> Starting with binutils-2.16.90.0.3, instructions like
>> 
>>     lea 0x0(%eax),%eax
>> 
>> began compiling into the exact same byte sequence as
>> 
>>     lea (%eax),%eax
>> 
> 
> I have been thinking to use 0x0B, 0x0W, 0x0L to indicate the size
> of displacements.
> 

  That would be useful.  However, 0x0B is a valid hex number!  How about using
the same syntax as m68k, where you'd say 0x0.b, 0x0.w or 0x0.l ?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Jan Beulich]

This stripping is intentional; I'm running into this in many cases where structure offsets are generated (i.e. through a C translation), and the zero offset gets needlessly retained. The point is that you anyway can't force the assembler to everything, like use a 32-bit displacement when an 8-bit one (or even none) suffices. If that's already impossible, then adding this additional thing is no issue at all in my opinion. Jan

>>> "Dave Korn" <dave.korn@artimi.com> 06.05.05 15:56:52 >>>
----Original Message----
>From: Jan Beulich
>Sent: 06 May 2005 13:04

> When explicitly specified, gas encoded a pointless zero displacement in
> memory addressing forms. Since this is not normally desired and was most
> likely just an oversight, this patch adds an adjustment to eliminate the
> displacement in that case.

  I'm not sure if I've fully understood the intent of this patch, but I
think you're saying that if someone writes

        mov %eax,0(%edi)

the assembler will emit

   4 0003 8907          mov %eax,(%edi)

and not

   2 0000 894700        mov %eax,0(%edi)

yes?  Nothing the user _explicitly_ specifies should ever be discarded IMO.
What if someone wants to write self-modifying code that stores varying
offsets into that field?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[DJ Delorie]

> What if someone wants to write self-modifying code that stores
> varying offsets into that field?

Being one of those people, the answer is "use .byte".

We don't trust assemblers (or linkers) to be dumb any more.

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[H. J. Lu]

On Fri, May 06, 2005 at 06:33:00PM +0200, Jan Beulich wrote:
> This stripping is intentional; I'm running into this in many cases where structure offsets are generated (i.e. through a C translation), and the zero offset gets needlessly retained. The point is that you anyway can't force the assembler to everything, like use a 32-bit displacement when an 8-bit one (or even none) suffices. If that's already impossible, then adding this additional thing is no issue at all in my opinion. Jan
> 

Please check out

http://people.redhat.com/drepper/tls.pdf

elf_i386_relocate_section and elf64_x86_64_relocate_section to make
sure that TLS optimization, which depends on the exact length of
the instruction, won't get affected. 

I still prefer to fix compiler instead of assembler.


H.J.

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Jan Beulich]

>>> "H. J. Lu" <hjl@lucon.org> 06.05.05 18:50:33 >>>
>On Fri, May 06, 2005 at 06:33:00PM +0200, Jan Beulich wrote:
>> This stripping is intentional; I'm running into this in many cases where structure offsets are generated (i.e. through a C translation), and the
>> zero offset gets needlessly retained. The point is that you anyway can't force the assembler to everything, like use a 32-bit displacement
>> when an 8-bit one (or even none) suffices. If that's already impossible, then adding this additional thing is no issue at all in my opinion. Jan
>> 
>
>Please check out
>
>http://people.redhat.com/drepper/tls.pdf 
>
>elf_i386_relocate_section and elf64_x86_64_relocate_section to make
>sure that TLS optimization, which depends on the exact length of
>the instruction, won't get affected. 

I will.

>I still prefer to fix compiler instead of assembler.

I'm not sure what compiler fix you're referring to here. I'm referring to e.g. Linux' asm-offsets logic, which can easily create zero offsets, and which the compiler has no way to deal with.

Jan

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[Jan Beulich]

>Please check out
>
>http://people.redhat.com/drepper/tls.pdf 
>
>elf_i386_relocate_section and elf64_x86_64_relocate_section to make
>sure that TLS optimization, which depends on the exact length of
>the instruction, won't get affected. 

This can't be affected due to the O_constant check surrounding the whole construct:

    if ((i.types[op] & Disp) && i.op[op].disps->X_op == O_constant)

Jan

Re: [PATCH] x86: suppress emission of zero displacements in memoryoperands

[H. J. Lu]

On Mon, May 09, 2005 at 09:50:26AM +0200, Jan Beulich wrote:
> >Please check out
> >
> >http://people.redhat.com/drepper/tls.pdf 
> >
> >elf_i386_relocate_section and elf64_x86_64_relocate_section to make
> >sure that TLS optimization, which depends on the exact length of
> >the instruction, won't get affected. 
> 
> This can't be affected due to the O_constant check surrounding the whole construct:
> 
>     if ((i.types[op] & Disp) && i.op[op].disps->X_op == O_constant)
> 

OK. Approved.


H.J.