Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!ucselx!bionet!agate!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Metacompiling and C Forth 83
Message-ID: <9012102058.AA04446@ucbvax.Berkeley.EDU>
Date: 10 Dec 90 20:00:01 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 35

>  I am happier with the idea of bringing up a Forth quickly by using  your C
> Forth 83 approach than I am with the MASM approach.  ...
> I have been under the impression that to put Forth on a new machine  using
> your C approach requires that one have a C compiler available on  that
> machine.  Am I in error on this point?  If the C compiler is  required it
> would still seem to leave a place for something like eforth  on various
> systems.

C Forth is a good way to go to get Forth running on a full-blown system
based on some J. Random processor.  Most new full-blown systems these days
tend to run Unix, and tend to come with a C compiler.

But that's not what I was talking about in the discussion about MASM and
eForth.  I was suggesting that, rather than using MASM as a "poor man's
cross compiler" (thus limiting the development platform to a PC, making
life hard for everybody, and making Bill Gates even richer), it would be
better to use a metacompiler.  That metacompiler could be written in Forth,
and by running it on top of C Forth 83, it would run on anything that anybody
is likely to want to use as a development platform.  (And C Forth 83 is cheap).

MASM is a wretched cross-development tool, as Dr. Haskell found out.
It doesn't handle byte order, alignment, or loader format problems.
You end up having to write a clumsy program in some other external language
(e.g. F83 or C or whatever) in order to patch around those problems.

With a metacompiler, you can factor out access procedures to handle the
aforementioned problems.  You could even implement those procedures to
*generate assembler source code* if you wanted.  For example, the "putbyte"
procedure could easily output a text line line like ".DB 12" or whatever.

Metacompilers can be relatively simple; the F83 metacompiler is a good
example.  Since eForth uses CATCH/THROW, you wouldn't even have to solve
the limited forward reference problem.

Mitch Bradley, wmb@Eng.Sun.COM