Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!ncc!idacom!andrew
From: andrew@idacom.uucp (Andrew Scott)
Newsgroups: comp.lang.forth
Subject: Forth optimization  (was Re: Postfixer Forth)
Message-ID: <1990Aug29.171704.15174@idacom.uucp>
Date: 29 Aug 90 17:17:04 GMT
References: <1990Aug24.221345.14475@idacom.uucp> <1635.UUL1.3#5129@willett.pgh.pa.us>
Organization: IDACOM, a division of Hewlett-Packard
Lines: 46

Doug Philips writes:
> (I was quite surprised when you actually showed up on the net.  Another
> lurker out in the open!)

I've been around for quite some time.  I can usually be found in
rec.sport.hockey.   :-)

> I do have a question about your system.  For example:
>
> IF ( code-series-1 ) ELSE ( code-series-2 ) THEN ( code-series-3 )
>
> would it be reasonable, possible, sane, to be able to push copies of
> code-series-3 into each branch and see if the optimizer can do better that
> way?

Hmm.  Good point.  The code generated by:

( n \ condition ) IF  5  ELSE  9  THEN +

would be less optimal than

( n \ condition ) IF  5 +  ELSE  9 +  THEN

because the sequence LIT + combines into a single instruction.


I think it would be more trouble than the results warrant to handle this
situation.  I would have to save all the compilation tokens in the entire IF
construct before the decision could be made.  Currently, the optimizer is
quite small because I only have to queue up 4 tokens at most (the longest
sequence in the optimization rules set is 4 words).

There are many more optimizations that my compiler could tackle, but I don't
want to end up with a mammoth system.  I get decent results from the sequence
optimizations I perform now.


I was going to experiment with an optimizer that worked at the assembly
language level.  Each Forth primitive (like DUP) could be coded in "machine"
primitives (like POP and PUSH).  Redundant POPs and PUSHes could be eliminated
and values could remain in registers over a long span of code.  Movement
to the stack in memory would only take place when necessary.  This approach
might yield big speed improvements on non-Forth processors.
-- 
Andrew Scott	| mail:		andrew@idacom.uucp
		| - or -	..!uunet!ubc-cs!alberta!idacom!andrew