Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!ames!pacbell!noe!marc
From: marc@noe.UUCP (Marc de Groot)
Newsgroups: comp.lang.forth
Subject: Re: Forth Compilation (again) ?
Message-ID: <665@noe.UUCP>
Date: 2 Aug 89 17:41:43 GMT
References: <114600003@uxa.cso.uiuc.edu>
Sender: usenet@noe.UUCP
Reply-To: marc@noe.UUCP (Marc de Groot)
Organization: Noe Systems, San Francisco
Lines: 47

In article <114600003@uxa.cso.uiuc.edu> ews00461@uxa.cso.uiuc.edu writes:
>I've seen Forth systems that generate object code.  How is usually done ?
>Inline code ?  Lots of jsr (subroutine calls) ?  Are they simply using
>the dictionary as a "symbol table" ?

I have seen (alas, only briefly) two interpreters that address this.  The
first if JForth for the Amiga.  It is a subroutine-threaded Forth (i. e.
compiled JSR's).  It is flexible, allowing object code compilation to
be mixed with traditional threaded code pointers.  There are some neat
parameters you can control (like, to what level the compiler will
de-thread the code).
Wil Baden gave a talk at one of the Forth conventions about turning
Forth right into 68000 code.  I will give an example, but please bear with
me: it's been years since I wrote 68000 assembler.  I will probably get the
mnemonics wrong.

Let's say that register A0 points at the parameter stack.  DROP can be
coded as
	addq	A0, 4

DUP becomes
	movl	(A0), (A0)-

I'll leave the rest of the standard primitives as an exercise for the
reader (along with 50 or so push-ups :-).

>It seems to me that storing assembler mneumonics for each dictionary
>word and simply generating inline code would work, but I'm sure there
>are other algortihms.  Also, some flexibility is necessary I'm sure
>because pure inline expansion of all words would yield HUGE code.

You are right.  I once wrote a word called [DECOMPILE] .  If you
said [DECOMPILE] WORDS inside a colon definition, it would expand
the reference to WORDS into in-line code.  WORDS (actually it was
VLIST) expands to about 2.5k bytes!

More sophisticated is the concept of the optimizing compiler for Forth.
Each word capable of compiling code should look at the code already compiled
(or some representation thereof) and eliminate unnecessary operations.
The optimizing compiler that Chuck Moore put in cmFORTH for the Novix
chip is a fascinating example of how to do it, although his coding
style is pretty unreadable :-( .
-- 
Marc de Groot (KG6KF)                   These ARE my employer's opinions!
Noe Systems, San Francisco
UUCP: uunet!hoptoad!noe!marc
Internet: marc@kg6kf.AMPR.ORG