Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sgi!key!ken
From: ken@key.COM (Ken Kofman)
Newsgroups: comp.lang.forth
Subject: FORTH, RISC, and other new architectures
Summary: Optimizing FORTH??
Message-ID: <975@key.COM>
Date: 1 Aug 89 18:41:47 GMT
References: <385@ryn.esg.dec.com>
Reply-To: ken@samaria.key.COM (Ken Kofman)
Organization: Key Computer Laboratories, Fremont
Lines: 40

I have been a FORTH fan ever since I learned the language about
a year and a half ago.  I have also been following some of the
new cpu architectures, such as mipsco, AMD29000, transputer, etc,
and have been wondering about the extreme performance hit that
FORTH must take on these cpus compared to languages like C.

It would be extremely difficult for FORTH to take full advantage of
the large register files the RISC chips provide, unless a FORTH
compiler is provided, or the programmer resorts to assembler :(.
Even on the transputer, which, at first glance, seems particularly
well suited to FORTH, there must be a good deal of time wasted 
maintaining the stack- -the transputer's stack is only three deep.

Intrinsic to the current RISC philosophy is the idea that memory
accesses are BAD, and should be avoided where possible.  RISC chips
therefore provide a large register set, and usually a memory cache.
A FORTH program will be making many memory accesses.  The cache will
sometimes help, but will often prove ineffectual.  One would want the
top of the stacks to be cached, and usually they will be.  However, 
these caches are usually direct mapped, sometimes are 2 way.  There is
a reasonable chance that other data will blow the stack tops away at any
time during program execution.

I think I'm beginning to ramble.  Basically, it seems that the current
crop of cpu architectures, with multiple functional units with varying
data latencies, and large register sets do not work well with FORTH.
register sets do not work well with FORTH.  Am I missing something?
Has anyone out there used FORTH on new and/or interesting architectures?

Very curious,

ken



-- 
-------------------------------------------------------------------
Disclaimer:  Don't blame me, Amdahl MADE me say it.
Ken Kofman
ken@samaria.key.com				...!pacbell!key!ken