Re: writing an assembler!

Kirk Hays <khays@sequent.com> wrote:
>IOW, you write the macro language interpreter, then write your
>assembler as a set of macro procedures describing all the
>instructions, their opcodes, and any assembly state that affects the
>emitted binary code... NEVER
>forget that the macro language is a string manipulation language.
>Look at a SNOBOL (or ICON, perhaps) manual to discover your string
>manipulation primitives. Keep the interpreter generic...


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.


(Control structures? Tcl has a full set, including a flexible
procedure mechanism. Pattern matching? Yup, full regular
expressions. Symbol tables? Tcl arrays are already an efficient
general-purpose table mechanism, scaling well to quite large sizes.
User procedures as full equivalents of builtins? Yup. And suitable
books, courses, newsgroups, consultants, and commercial support are
already available on the open market. Similar comments apply to
several other languages.)


For starters, you can simply implement the whole thing (including the
central pattern-match loop) in the string language. If performance
becomes an issue, then it *may* be worthwhile recoding key bits, like
the loop, in C or whatever. A lot of the time, it turns out *not* to
be worthwhile, and you've saved a lot of extra work. (And bosses,
users, etc., are a lot more tolerant of a working tool that's half as
fast as it should be than of a fast tool that only half works.)
--
Henry Spencer henry@spsystems.net
(aka henry@zoo.toronto.edu)
--

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