Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!decwrl!ucbvax!SUN.COM!wmb
From: wmb@SUN.COM (Mitch Bradley)
Newsgroups: comp.lang.forth
Subject: Re: FORTH, RISC, and other new architectures
Message-ID: <8908041410.AA10853@jade.berkeley.edu>
Date: 4 Aug 89 05:39:17 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu>
Organization: The Internet
Lines: 48

Speed isn't everything.  It's fun to play the "my system is faster
than your system" game, but to a large extent, for the stuff I do
most often, even a garden variety 68000 is plenty fast.  (On the other
hand, a garden variety 8088 is not fast enough for anything I
can think of :-)

On a 10 or 20 MIPs CPU chip, I will gladly spend a lot of those
blazing CPU cycles in order to make my life as a programmer easier.
In particular, I like threaded code a lot, because it is easy to
decompile and easy to debug.  In so many applications, it's plenty
fast, and when it's not, writing a very few code words gets you
within epsilon of the best speed you could hope to achieve anyway.

Before you get out your flame throwers, I realize that there are
some applications that demand the ultimate in speed.  There are also
a lot of applications that do not.

Now, back to something closer to the original question of how Forth
can or cannot use large register files on RISC chips.  SPARC chips
generally have 7 or 8 windows of 16 32-bit registers each.  These
registers are quite effective as a "cache" for C stack frames, but
they are pretty much useless for Forth.  My SPARC Forth implementation
just sits in one of the registers and uses the registers in that
window as general registers.  There is an interpreter pointer, a data
stack pointer, a return stack pointer, a user area pointer,
a code base pointer, and a top of stack register.  The rest of the
registers are just scratch registers.  Pretty basic, obvious, boring
design.  It could be faster, but it still spend most of its
cycles waiting on the disk, or the Ethernet, or the UART, or me.

One interesting side effect of this non-use of the window register
mechanism is that Forth becomes an excellent debugger for C programs
like the Unix kernel.  Since Forth never triggers overlow/underflow
of this stack frame "cache", it is innocuous with respect to the
code that it is trying to debug.

If I had it to do over, I wouldn't have cached the top of stack in
a register.  The 5 or 10% speedup that results in not worth the
trouble it causes in trying to explain to people how to write code words.

By the way, the SPARC Forth kernel was the very first high level language
program ever to run on real SPARC hardware.  When the first Sun 4/260
prototypes came in, a bug in the memory logic prevented C programs
from being able to work.  Forth ran just fine, and was used to debug
the machine to the point of being able to run C.  (The SPARC Forth kernel
had been previously debugged using an instruction set simulator).

Mitch