Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!ENG.SUN.COM!Mitch.Bradley
From: Mitch.Bradley@ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Re : Forth in C
Message-ID: <9104191330.AA16232@ucbvax.Berkeley.EDU>
Date: 19 Apr 91 02:31:20 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Mitch.Bradley%ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 55

> I use the Sun SPARC station 2 and Sun-3/160 (68000) machines both run UNIX
> systems. And there are 3 versions of FORTH on them.
>
>    Sun Forth - written by Mitch Bradley (68000)
>    PolyForth - written by Forth Inc.    (68000)
>    OPEN BOOT PROM - written by Sun Microsystem, Inc. (SPARC)

More precisely, Open Boot PROM was written by Mitch Bradley who happens
to work for Sun Microsystems, Inc.  Several people helped me, but at least
in the early days, I wrote most of the code.

There is also a "Sun Forth" for SPARC.  99% of the source code is identical
among the 680x0 and SPARC versions of "Sun Forth" and Open Boot.  The same
source code is extended in the direction of a Unix application to form Sun
Forth, and in the direction of a firmware boot/debug monitor to form Open
Boot PROM.


> I suppose OPEN BOOT PROM is the first version of Forth on RISC machines.

This might be hard to verify, because lots of machines can justifiably
claim to be RISC machines.  For example, the ancient Data General Nova
architecture would qualify as a RISC by most objective analyses.

The precursor to Open Boot (essentially, the standalone version of Sun Forth)
was indeed the first version of Forth to run on SPARC.  In fact, it was the
first significant program of any sort to run on SPARC hardware.  The first
SPARC board had a bug that prevented the main memory from working right,
so C programs wouldn't work (the C call-frame stack couldn't be managed
right).  I made a Forth PROMs that ran entirely out of the on-board cache,
and we used Forth to debug the machine to the point where C programs would
work.


> Forth is the threaded interpretive language (TIL) and it uses the threads to
> chain its commands (words). It is good for small computer, because by threads
> the only small memory is requird. But this is also the problem that will kill
> the Forth !

The thing that is hurting Forth the most is not execution speed (that can
easily be fixed; Forth can be compiled to native code just like any other
language).  The real problem is that Forth is largely unknown in the
mainstream computer science community, so most people who are trained
in programming have not even heard of Forth.

Us technical people sometimes like to look for technical reasons to explain
Forth's relative unpopularity, but in reality, marketing factors are probably
more important.

A similar situation exists with natural languages.  English is spoken
in many places in the world, not because English is a particularly good
language, but mostly because England had a worldwide empire.


Mitch Bradley, wmb@Eng.Sun.COM