Scheduling x86 dispatch windows
Mon Jun 14 13:14:00 GMT 2010
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
> >> 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
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
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
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.
More information about the Binutils