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.
