johnl@ima.ISC.COM (12/13/87)
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...}. -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request