Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!ncc!idacom!andrew
From: andrew@idacom.uucp (Andrew Scott)
Newsgroups: comp.lang.forth
Subject: Re: Forth optimization  (was Re: Postfixer Forth)
Message-ID: <1990Sep7.231911.20882@idacom.uucp>
Date: 7 Sep 90 23:19:11 GMT
References: <1990Aug29.171704.15174@idacom.uucp> <1676.UUL1.3#5129@willett.pgh.pa.us>
Organization: IDACOM, a division of Hewlett-Packard
Lines: 31

Doug Philips writes:
>>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.

> Do you mean that you'll have another virtual machine with PUSH POP etc.
> or do you mean the real machine level instructions.  I think you could
> probably do a good machine code peephole optimizer that way.

Currently, my optimizer makes the following translation:

	Forth sequences --> native code instructions

The idea was to create a multi-stage optimizer/translator:

	Forth word --> sequence of virtual primitives
	virtual primitive reduction (peephole optimization)
	sequence of virtual primitives --> native code instructions


This idea looks attractive for creating native code target compilers for
several CPUs.  The tough part would be in coming up with the set of atomic
primitives that could be combined into appropriate instructions for a wide
variety of CPU instruction sets.  The target compiler engine could be the
same for many CPUs; only the translation rules would differ.
-- 
Andrew Scott	| mail:		andrew@idacom.uucp
		| - or -	..!uunet!ubc-cs!alberta!idacom!andrew