Path: utzoo!attcan!uunet!midway!ncar!umich!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.lang.forth
Subject: Re: Forth on RISC processors
Keywords: Forth, RISC processor
Message-ID: <10887@pt.cs.cmu.edu>
Date: 28 Oct 90 12:09:06 GMT
References: <15603@reed.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 52

In article <15603@reed.UUCP>, celarier@reed.bitnet (Stuart Celarier,<None>,2369490,2369386) writes:
>... comments regarding implementing Forth on a RISC processor.
>         1.  The computational model of Forth is a stack machine; however
> RISC processors are not stack machines, ...
 
As with anything on a RISC, your performance will be determined by
the quality of your compiler.  You will need at the very least 
a peephole optimizer that can do things like change "7 +"
from "push(7) +" to "add r1,7".  In general the idea is to 
change a sequence of in-line Forth primitives into a series 
of register-based operations, thereby eliminating much of the
stack manipulation overhead.  Such compilers do exist, but they
are currently the exception rather than the rule (perhaps someone
out there can name one -- JForth??).
 
> ... since the registers participating in an operation
> are hardcoded in that operation.
 
This is one of the reasons it is so attractive do subroutine
inlining on RISCs -- for better register allocation.  Such inlining
is not needed on stack hardware.  So, you will find a high-quality
RISC Forth compilers doing in-lining of short operations.  You will
probably also find they can't use as many registers for Forth as
for C.
 
> ..        I guess this can be summarized with:  are RISC processors designed
> for larger granularity code than Forth is?  (Note the dangling participle.)
 
Forth/stack-based processors tend to be more "agile" than RISCs.
Specifically, they don't have branch delay slots and they do
support subroutine calls as a quick primitive operation.
A high-quality RISC Forth compiler will try to arrange to fill
branch delay slots for you.
 
>         5.  Any other comments, such as pitfalls, success stories, technical
> journals, abandoned projects, contacts to talk with, etc. are GREATLY
> appreciated.
 
Mitch Bradley at Sun does SPARC-based Forth, but I believe he
works at a higher level (Mitch -- how does the optimizing C
compiler do at translating stack->registers?)
Tim Olson at AMD posted here that he had done some low-level work
with Forth on an AMD 29000.  (AMD 29000 has a register stack).
 
On the other hand, you could just use a stack-based chip (such
as the Harris RTX 2000, etc) if you have an embedded application.
 
  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
Senior scientist at Harris Semiconductor, and adjunct professor at CMU.
I don't speak for them, and they don't speak for me.