Re: writing an assembler!

"Dr Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
1 Jul 1998 22:49:08 -0400

          From comp.compilers

Related articles
slightly off topic -- writing an assembler! SAMIGWE@worldnet.att.net (samuel) (1998-06-24)
Re: slightly off topic -- writing an assembler! khays@sequent.com (1998-06-24)
Re: writing an assembler! lindsay-j@rmc.ca (John Lindsay) (1998-06-27)
Re: writing an assembler! henry@spsystems.net (1998-06-28)
Re: writing an assembler! ok@atlas.otago.ac.nz (Dr Richard A. O'Keefe) (1998-07-01)
Re: writing an assembler! nr@labrador.cs.virginia.edu (Norman Ramsey) (1998-07-03)
Re: writing an assembler! telnet@wagner.Princeton.EDU.composers (1998-07-08)
| List of all articles for this month |
From: "Dr Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
Newsgroups: comp.compilers
Date: 1 Jul 1998 22:49:08 -0400
Organization: Department of Computer Science, University of Otago
References: 98-06-126 98-06-144 98-06-160
Keywords: assembler, design

Henry Spencer wrote:
> Even better: use an existing string-oriented extension language like
> Tcl, instead of inventing your own macro-language interpreter. You
> expend less effort and probably get a more satisfactory language.


Let me suggest a related but significantly different approach. The
central question is what you are going to _do_ with your assembler.
If the aim is to be the back end of a compiler, you want it to be
utterly simple and blindingly fast. The _last_ thing you want is
macro facilities. This is the approach taken by the Unix assemblers,
and it works very well _in that context_. Mind you, Sun's assembler
has an optimisation pass in it, which can be very helpful for someone
writing code by hand, and can also be a rather unpleasant pain if you
were expecting to get the bits just so.


If, on the other hand, you expect human beings to write large chunks
of code in your assembler, you have rather different things to worry
about, and speed is not such an issue. Correctness is! Macros as
such are not quite as easy to get right as you might suppose.


Back in the days of the B6700, the B6700's networking stuff was
handled by a separate processor. That processor had its own
programming language, NDL (network definition language). The NDL
compiler made use of the technique I am about to describe; it is
not my own invention but goes back to the 60s.


The idea was that you don't really CARE whether there is an
assembler or not. All you care about is that your program get
assembled. So instead of writing a text that is to be processed
by an assembler, you write a *program* that, when run, does the
job of assembling the code you want. Burroughs used Burroughs
Extended Algol as the assembler implementation language; it had
(for that matter, still has) somewhat C-like macros of its own
(but respecting block scope), so some common things could be set
up as Algol macros. But things like opcodes were handled as Algol
procedures. Imagine something like this.


Instead of


foo: ldy 28
lda bar,y
add ugh
sta ugh


have this:
for pass := 1 step 1 until 2 do begin
entry(foo);
ldy(28);
lda_y(bar);
add(ugh);
sta(ugh);
end


Your assembler, had you written one, would have had to deal with some
kind of internal structures to represent addresses and so on, _and_
with parsing an external form. Done this way, you still have to come
up with the internal structure, but you _don't_ have to write any
parsers, the Algol compiler does that for you. What is a macro? It's
just a procedure. Presto: strong static type checking for macro
calls!


These days, my language of choice for doing this would be Lisp or Ada
(sensible macros are about *trees*, not strings!) but you can
certainly use C as an assembler quite effectively.
[It's a disgusting hack, but it's a great disgusting hack. -John]




--


Post a followup to this message

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