[Bug gas/10777] New: Macro processing altercation

[konrad dot schwarz at siemens dot com]

The state of macro processing in gas is rotten.  I say this after spending an
exorbitant amount of time in getting it to work on problems that other
assemblers, such as from ARM, Tasking, Fujitsu have no problems with.  (This is
not helped by the fact that GAS's listing facility is flaky, but that is a
different matter).

For example, consider the task of using a symbol name that is computed, for
example, setting the symbols .Lvector_used_0, .Lvector_used_1, ...
.Lvector_used_255 to zero.  The solution I have come up with after considerable
experimentation is:

        /* concat required because in gas, .altmacro %
        expansion only works at the start of a word */
        .macro  concat  s1, s2, s3, s4, s5
                .noaltmacro
                \s1\s2\s3\s4\s5
        .endm

        .Li = 256
        .rept   .Li - 0
                .Li = .Li - 1
                .altmacro
                concat  .Lvector_used_, %.Li, < = 0>
        .endr

``Immediate'' expansion of a symbol is possible only in `.altmacro' mode, using
the `%' operator.  On the other hand, `.altmacro' mode uses `<' to delimit
strings, which conflicts with its usual meaning of ``shift left''.  So it is not
a good idea to switch to `.altmacro' mode globally; instead it should be done
only were necessary.  Hence the call to `.altmacro' in the loop and the call to
`.noaltmacro' in the concat macro.

Even in `.altmacro' mode, `%' expansion is only recognized at the beginning of a
word.  Thus, the expression .Lvector_used_%.Li (which corresponds to
vector_used [i] in a C-like language) must be written as separate words.  Hence
the `concat' macro, which allows a separate round of evaluation.

The call to `concat' represents the line
    .Lvector_used\(.Li) = 0
if `\(_expr_)' meant to evaluate `_expr_' immediately.  And in fact, I would
like to recommend this as a way forward.  If `\()'  were extended in this way,
use of GAS would be much more straightforward, as demonstrated by this example.
 The parenthesis serve to clearly delimit the expression; thus, it can be
embedded into the middle of a word.

As another thing, clarification of the way macro arguments are parsed would be
in order.  It seems from the example in (as.info)Macro that arguments can be
enclosed in double quotes and that they are stripped before expansion, but this
is not stated anywhere.

I realize that implementing `\(expr)' is not entirely trivial, so I would like
to request built-in support for M4 as a preprocessor, just like the Unix System
V assembler.  In particular, the System V assembler has a `-m' option which
invokes m4 on its source and assembles the result.  This option is important for
easy integration with `make' default rules: e.g., in GNU make, adding `-Wa,-m'
to ASFLAGS would enable using just the default rule catalog to compile such
sources; otherwise, a separate rule needs to be created and a naming scheme
(such as a suffix) be reserved for these files.

The benefit of M4 is that it is well documented, extremely capable, and offers a
clear separation between the preprocessing and assembly phases of processing,
similar to C.  It is also possible to view the output of preprocessing for
debugging, whereas various errors cause GAS to omit the listing file or to write
it out incompletely.  In such a case, correcting parse errors is extremely
tedious -- I had to resort to adding deliberate syntax errors to
zero in on the locations of actual errors.

In contrast, the use of link-time symbols as preprocessing variables in GAS
requires them to be marked as temporary (prefixed with .L in ELF files), which
is detrimental to legibility, and the GAS 1-pass approach makes it hard to
figure out what value will actually be used.

Note that for example the IBM mainframe assembler similarly differentiates
between variables used by the macro processor and symbols.

The only drawback I can see of such a ``phased'' approach is that symbol values
cannot direct preprocessing.  As the IBM example shows, this is a viable trade 
off.

-- 
           Summary: Macro processing altercation
           Product: binutils
           Version: 2.19
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gas
        AssignedTo: unassigned at sources dot redhat dot com
        ReportedBy: konrad dot schwarz at siemens dot com
                CC: bug-binutils at gnu dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=10777

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.