koopman@A.GP.CS.CMU.EDU (Philip Koopman) (03/24/88)
I'm in the process of selecting a working environment for use with the WISC CPU/32 processor. The issues of how to deal with a hardware-rich environment are quite interesting, and different than the issues that arose during Forth's creation in the tightly constrained world of early micros. Does anyone have comments on what kind of support environment is appropriate for Forth programming on high-speed machines with lots of memory and disk space? Some of the issues I am struggling with include: - screens vs. text files vs. blocked text files - floating point as part of the system environment - string handling - whether a built-in heap manager is appropriate - debugging support - source code migration between 16- and 32-bit environments - multi-tasking (pre-emptive) - lessening the culture shock to UNIX/C programmers learning Forth ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Phil Koopman 5551 Beacon St. ~ ~ Pittsburgh, PA 15217 ~ ~ koopman@faraday.ece.cmu.edu ~ ~ ~ ~ I'm a PhD student at CMU, and I do some ~ ~ work for WISC Technologies. ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ilan@cup.portal.com (03/26/88)
>I'm in the process of selecting a working environment >for use with the WISC CPU/32 processor. The issues > screens vs. text files vs. blocked text files Need to develop or purchase existing source for screens AND text files. > floating point as part of the system environment Depending on your hardware. If you have floating point h/w by all means develop a few simple floating point words to use it. Otherwise, there are several s/w floating point implementations 'floating' about. > string handling Inherent in most FORTHs. > whether a built-in heap manager is appropriate Since FORTH is inherently stack oriented, it really already has a heap manager as well as a stack manager !!! In fact a derivative of FORTH called STOIC has 5 different stacks or heaps (depending on how you look at it). Furthermore, in some FORTHs you can have as many stacks and heaps as you have memory for pointers and stack data. > debugging support Debugging facilities are immbeded within most FORTHs, its just a matter of switching it on and sometimes writing a few more words to extend the capabilities to suit your requirements. > source code migration between 16- and 32-bit environments That is a great idea, but need be extended to be flexible for use in 8-16-32-64 bit environments. I have not seen many FORTHs with this capability, although it can be implemented -- the tradeoff is speed and a bit more code in the system. > multi-tasking (pre-emptive) Several different implementations of MultiTasking exist today, you just need to pick the right one, or a combination. > lessening the culture shock to UNIX/C programmers learning Forth It should be fun for anyone enjoying computers to learn FORTH. It may be difficult to read (for most of us), but its extremely powerful and FUN. OTHER areas to consider: Use interpretive modes for development, but the final product should be compiled and optimized code. Must have source control as the project progresses. With more than one developer you're asking for trouble if you don't have STRICT guidelines at the onset (meaning day UNO). Must have automated documentation and communications facilities. That is, whenever any developer write ANY words, the code must be immediately documented and transported ELECTRONICALLY to other developers' Email Boxs which ALARM the 'other' developers to the fact (active alarms - its THAT important). Must have the possible documentation facilities. With FORTH you'd better. Good Luck.. - ILAN RABINOWITZ - with ILANET(tm) ilan_rabinowitz@cup.portal.com or sun!cup.portal.com!ilan_rabinowitz