4.1. External filters
Whatever is the macro support from your assembler,
or whatever language you use (even C!),
if the language is not expressive enough to you,
you can have files passed through an external filter
with a Makefile rule like that:
%.s: %.S other_dependencies
$(FILTER) $(FILTER_OPTIONS) < $< > $@ |
4.1.1. CPP
CPP is truly not very expressive, but it's enough for easy things,
it's standard, and called transparently by GCC.
As an example of its limitations, you can't declare objects so that
destructors are automatically called at the end of the declaring block;
you don't have diversions or scoping, etc.
CPP comes with any C compiler.
However, considering how mediocre it is,
stay away from it if by chance you can make it without C.
4.1.2. M4
M4 gives you the full power of macroprocessing,
with a Turing equivalent language, recursion, regular expressions, etc.
You can do with it everything that CPP cannot.
See
macro4th (this4th) or
the Tunes 0.0.0.25 sources
as examples of advanced macroprogramming using m4.
However, its disfunctional quoting and unquoting semantics force you to use
explicit continuation-passing tail-recursive macro style if
you want to do advanced macro programming
(which is remindful of TeX -- BTW, has anyone tried to use TeX as
a macroprocessor for anything else than typesetting ?).
This is NOT worse than CPP that does not allow quoting and recursion anyway.
The right version of M4 to get is GNU m4 1.4
(or later if exists),
which has the most features and the least bugs or limitations of all.
m4 is designed to be slow for anything but the simplest uses,
which might still be ok for most assembly programming
(you are not writing million-lines assembly programs, are you?).
4.1.3. Macroprocessing with your own filter
You can write your own simple macro-expansion filter
with the usual tools: perl, awk, sed, etc.
It can be made rather quickly, and you control everything.
But, of course, power in macroprocessing implies "the hard way".