Macro assemblers, just say "C".

Some people are saying compilers producing assembly code output is good
because it puts pressure on the assembler writer to make it fast.
One correspondent objected that this is actually a bad thing because it
means that features are omitted, e.g. macro processing.


I have used assemblers with powerful macro facilities, and the UNIX
assemblers, and I am firmly on the keep-it-simple side. Having an
assembler of fairly extreme simplicity needn't stop you using macros.


I got this idea from Burroughs: they had a *weird* datacomm processor
living inside their big machines. The network description language
compiler generated not just code for terminal control methods, but
also a specialised variant of the DCP's kernel. They used an
extremely powerful macro language for this: Algol! (Actually, they
used Algol as a two-pass assembler: your "assembly program" was a
procedure which was called twice. Neat hack.)


These days, substitute Pascal or Modula or C for Algol. Why muck around
with yet another language (the macro control language) with pathetic data
structures when you can use a decent language? (Actually, Lisp or Prolog
is even better...)


This helps another way: we have several kinds of MC680x0 boxes here, but
the assemblers don't use the same mnemonics, commenting conventions, &c.
The answer? Write your assembly code in C, e.g.
movl(D0, b(A0,1234))
and link it with the appropriate back end to generate
mov.l %d0,1234(%a0)
or movl d0,a0@(1234)
or whatever. You can even do things like


#include <struct.h>


void ffch(Reg, Base, Offset, Size)
...
{
switch (Size) {
case sizeof (char) :
movb(b(Base, Offset), Reg); break;
case sizeof (short) :
movw(b(Base, Offset), Reg); break;
case sizeof (long) :
movl(b(Base, Offset), Reg); break;
default:
abort(); /* one is cleverer than this! */
}
}


#define load_field(Reg, Base, Struct, Field) \
ffch((Reg), (Base), \
fldoff(Struct,Field), \
fldsiz(Struct,Field))


struct demo { char a; long b; short c; };


... load_field(D0, A0, demo, b);


C makes a *MUCH* more powerful macro language than most assemblers have.
Another beauty of this approach is that people who don't want any macro
facility in the assembler aren't paying for it.


Don't forget the possibility of generating the C code from some sort of
tables using awk(1) {or, for IBM mainframe usees, SAS; it has been done...}.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.