I know some people have been talking about rewriting the assembler; I've
had some more thoughts on this over the past couple of days.
First, I think that our assembler is going to be a reference implementation
for those producing bytecode-emitting compilers. It does not need to be
fast, but it does need to be clear and easy to understand.
Some people have been talking about making the assembler more OO; in my
opinion, this is a mistake. OO programming has the great advantage that you
can abstract away a lot of the tricky bits, hiding the complexity. It however
has the disadvantage that you hide away the complexity. Let's make this a
nice, open, transparent program.
The way I've thought about doing it so far is not unlike the Unix toolset
model; small components doing a dedicated task. Assembly is essentially a
filtering process, and Unix filter techniques can be brought to bear on it.
For instance, I've just written a little component which takes the assembly
and expands the ops, turning "set" into "set_p_ic" or whatever it may be.
Granted, these components will share some library code, such as that to
parse out a line of assembly source, but I think that specialized elements
working on text is the way to go here.
The real advantage of this method, other than making the overall design
and process of the assembler easy to understand, is that we can slot in
optimizations as additional filters at any stage of the assembler's operation.
I'll produce a more specific PDD about how I'd like the assembler to look
if this idea makes any sense to anyone other than me.
--
Use an accordion. Go to jail.
-- KFOG, San Francisco
