KX10LYC0@TWNITRI1.BITNET (04/18/91)
> I'm looking for better options for a Forth implementation in C to port to > my UNIX box. I'm aware of cforth in the uunet archives, but it really > doesn't really do it for me, as it has 16 bit integers only, requires > blockfiles, upper case dictionary only, etc. I'm wondering if anyone has > implemented a richer environment, better integrated with the rest of the > UNIX environment. > > Thanks, > Andy Valencia > vandys@sequent.com 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) I believe the Sun Forth is a 32-bit Forth on hardware-riched environment (ex. workstation). Sun Forth abandoned the "block" concept in usual Forth, but used the UNIX file I/O system to handle data. I really get lots of fun from it on my Sun-3 machine. OPEN BOOT PROM is a stand-alone Forth developed by Sun, it is used to control the SPARC machine selftesting and system initialization on SBus. OPEN BOOT PROM adapts the Forth 83 standard and expands it to include some Sun's private words. I suppose OPEN BOOT PROM is the first version of Forth on RISC machines. Forth had been implemented on diverse computers, from microprocessors to supermini (ex. VAX machine), but not RISC machines previously. Usual Forth uses the tiny resource, like 64K bytes memory and 16-bit stack. But this is not practicle now. Modern computer has over 1 meag bytes memory and almost can support UNIX system. I strongly believe that Forth must modify itself if it want to survive in future. Parallel Processing is the computer trend, but I don't see any man or project using Forth to take care this problem. LISP is the common language that used on P.P., but why not Forth? 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 ! TIL will cause the CPU to spend most of its time on jump instruction, until it reaches to primitive words (machine language). This situation violates the "locality" rule in computer science. Small code size doesn't equal to faster speed ! I just wonder and interest if any one uses the Forth on Parallel Processing or RISC machines. Also Sun use the OPEN BOOT PROM, but it only uses the Forth for testing and initialization when power-on. If someone tell me that he uses the Forth to perform the Fast Fourier Transform (FFT), I think I will be very glad to hear that. ---------------------------- | | | Yin-Chih Lin | | kx10lyc0@twnitri1.bitnet | ----------------------------
Mitch.Bradley@ENG.SUN.COM (04/19/91)
> 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