Re: Added GAS functionality

[Ian Lance Taylor <ian at zembu dot com>]

   Date: Tue, 08 Feb 2000 09:33:55 -0500
   From: Timothy Wall <twall@alum.mit.edu>

   1) Expanding macro arguments without them having to be explicitly
   escaped.

As you probably know, gas supports this in MRI mode.

I can't think of any reason to make this the default, or to add a
runtime option to support it.  The goal of gas is to implement a
particular assembly language syntax.  For compatibility purposes, we
may support a different syntax for particular targets.  But for
targets which do not have compatibility issues, or for which the
current macro expansion is normal, I don't see any reason to support
anything else.

Life is simpler for assembly language programmers when assembly
language meta-syntax is the same across processors.  I think we should
strive to support a syntax which is sufficiently powerful for all
normal purposes.  I don't think we should try to support all
reasonable syntaxes.

(There actually is a runtime option to turn on MRI mode.  This is
because the m68k is a very popular microprocessor, and MRI mode is the
syntax used by the Motorola assemblers, but gcc uses a different
syntax (M.I.T. syntax, which is based on PDP-11 syntax).  People want
to use gcc while writing inline assembler in the familiar Motorola
syntax.  This requires the ability to switch in and out of MRI mode at
runtime.  This combination of issues is unlikely to arise for any
other processor.)

   2) Arbitrary strings assigned to symbols:

       .asg MYREG, "reg10"
       add MYREG, 10    // evaluates to "add reg10, 10"

   2a) Forced substitution with "2" above:

       .asg INDEX, "10"
   label:INDEX:
       add    INDEX, reg

   Evaluetes to

   label10
       add    10, reg

I don't see why this gives any power that you can't already get from
macros.

However, in general it's fine with me to add new pseudo-ops.  I see
this as different from the first case because we are not adding the
flexibility to change the behaviour of gas at runtime.  gas will
always behave the same way when it sees the .asg pseudo-op.

A feature like this would have to be implemented carefully, in order
to not lose any efficiency in the normal case, and to not create
future maintenance complexities.  Your description of the
implementation--particularly the inability to rely on
scrubbing--suggests that this is not the case.

Ian