Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tektronix!reed!celarier
From: celarier@reed.bitnet (Stuart Celarier,<None>,2369490,2369386)
Newsgroups: comp.lang.forth
Subject: Forth on RISC processors
Keywords: Forth, RISC processor
Message-ID: <15603@reed.UUCP>
Date: 26 Oct 90 19:46:44 GMT
Sender: news@reed.UUCP
Reply-To: celarier@reed.bitnet ()
Organization: UniSyn, Portland, OR
Lines: 48


	I would like to know if anyone has any experience, references or
comments regarding implementing Forth on a RISC processor.

Some of the relevant issues that I need to address (to my boss) are:

	1.  The computational model of Forth is a stack machine; however
RISC processors are not stack machines, instead they use a hefty number
of registers.  There is no stack support, such as push and pop
instructions, no stack pointer, the registers do not form any sort of
stack themselves (such as, e.g., the registers on the Intel 80x87 do).
	On such a processor, it would be an unacceptable waste of
resources to implement a stack in memory from scratch -- er, not to
mention slow.  Similarly, implementing a stack on a subset of the 
registers would involve an unacceptable amount of register to register
data manipulation, since the registers participating in an operation
are hardcoded in that operation.

	2.  If the stack machine model is abandoned for Forth on a RISC
machine, replaced with _something_ else, then the Forth word interface
-- you know, those wonderful stack transition diagrams that show you what
a definition does to the data -- must change as well.  Would this then
be recognizable as Forth to anyone else?  Would it be Forth?

	3.  Assuming that Forth can be implemented on a RISC processor, and
that it doesn't use a stack, then can Forth code be ported to this system?
See rehetorical questions above.

	4.  Forth gets its speed and to some extent its modularity from
working at a very low level, with very small pieces.  This means a rather
high frequency of branches (jumps, calls, returns).  On a RISC processor,
there is lots of hardware devoted to pipelining the execution of
instructions, as well as detecting branches far enough in advance of
their execution so that the instructions are already cached -- giving the
"zero wait branch".  Will coding little tiny pieces of code mean that
typically the processor will be performing much less than optimal, due to
constantly depleating the pipeline, branching more frequently than the
instruction processor can keep up with, not being able to simultaneously
execute fixed and floating point instructions, etc.?
	I guess this can be summarized with:  are RISC processors designed
for larger granularity code than Forth is?  (Note the dangling participle.)

	5.  Any other comments, such as pitfalls, success stories, technical
journals, abandoned projects, contacts to talk with, etc. are GREATLY
appreciated.

Stuart Celarier			Voice:  503/236-9490
celarier@reed.edu		  Fax:  503/236-9491