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

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 inmemoryoperands

[Dave Korn]

----Original Message----
>From: DJ Delorie
>Sent: 06 May 2005 17:41

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


  Oh well, it seems a shame from the
future-proofing-clean-design-and-maintainability point of view to have to
hard code opcode values as hex constants in your program when you have a
handy assembler right there that could do the work for you.....


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

Re: [PATCH] x86: suppress emission of zero displacements inmemoryoperands

[DJ Delorie]

> Oh well, it seems a shame from the
> future-proofing-clean-design-and-maintainability point of view

Go back to the "self modifying code" part.  At that point, you've
already blown most of the benefits of maintainable code ;-)

> to have to hard code opcode values as hex constants in your program
> when you have a handy assembler right there that could do the work
> for you.....

  There was a program to do that job, an "optimizing assembler", but
  Mel refused to use it.

  "You never know where it's going to put things", he explained, "so
  you'd have to use separate constants".

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.