This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Scheduling x86 dispatch windows


Hi,

On Sun, 13 Jun 2010, H.J. Lu wrote:

> > We shouldn't turn GNU x86 assembler into an optimizing assembler. Next 
> > people may ask assembler to remove redundant instructions, ...

Well, but currently nobody is asking for such thing, right?

> > Right now, when something goes wrong, people don't have to debug 
> > assembler since it is very unlikely that the problem is in assembler. 
> > When assembler starts to make changes to assembly input, we have 
> > another place where a bug may be introduced.

But that's the case also right now.  align directives are one example for 
the assembler not emitting a one-to-one mapping, jump instructions are 
another.

> >> The essence is we want to insert prefixes (as well as nops) according 
> >> to certain rules known at encoding time. ÂThe mechanism implementing 
> >> these rules can be abstracted (table driven?) and could be applicable 
> >> to any hardware having similar features.
> >
> > Can you implement them with new directives/pseudo instructions?
> >
> 
> I think you should take a look at
> 
> http://code.google.com/p/mao/

I find the direction this discussion takes a bit bizarre.  Quentins 
suggestions were grounded in the way GCC works.  It emits text, and 
expects the assembler to transform this into binary blobs.  Changing this 
fundmental property is so much work that it isn't sensible to suggest that 
as alternative to the proposal.

Also GCC prefers to use GNU as.  Suggesting to use a different as' also 
doesn't read realistic (or even desirable) in my book, at least not on 
platforms where other as' aren't supported right now.  Neither does a 
post-processing tool seem desirable, as we want to generate fast code by 
default.

Therefore the only two realistic (IMO) possibilities are to either change 
GNU as to ensure the hw constraints are observed, or to do the same change 
in GCC.

Doing the change in GNU as has the advantage that all insn lengths are 
available without any work, i.e. it will handle e.g. inline asm; and that 
relaxation also is implemented just fine (it exists already in order to 
decide which jump form it's going to use); it has a high chance of always 
emitting the correct sequences.  It has the disadvantage that GNU as would 
emit (no-op) prefixes that the asm author didn't write.

Doing the change in GCC has the advantage that it would know about this 
change in instruction size (and therefore also could calculate sizes of 
jumps more correctly).  It has at least the disadvantage to need to do the 
tedious job of ensuring all insn lengths are correct, which by necessicity 
won't be done for inline asm; even ignoring inline asm it's known to 
quickly bit-rot (despite Jakubs heroic efforts).  From that follows that 
it has a somewhat higher chance of emitting slow sequences.

I don't see realistic and desirable other options.  For completeness 
considerations (inline asm) I think changing GNU as is the better choice.


Ciao,
Michael.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]