This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: [PATCH] x86: suppress emission of zero displacements in memoryoperands
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Andreas Schwab'" <schwab at suse dot de>
- Cc: "'Jan Beulich'" <JBeulich at novell dot com>,<binutils at sources dot redhat dot com>
- Date: Fri, 6 May 2005 15:48:48 +0100
- Subject: RE: [PATCH] x86: suppress emission of zero displacements in memoryoperands
----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....