sohail@terak.UUCP (10/01/84)
I am looking for a version of forth that is written in C and will run under UNIX does any one know if such a forth exists -- Sohail Hussain uucp: ...hao!noao!terak!sohail phone: 602 998 4800 us mail: Terak Corporation, 14151 N 76th street, Scottsdale, AZ 85260
ee65xab@sdcc7.UUCP (Darin ) (10/04/84)
I am currently working on a FORTH simulation in C for personal use. The main difficulty so far is using direct memory access and management. The more I write, the more I realize I should have used assembly language. As is, I probably won't be able to push bytes, words, and doubles on the same stack and still have a decent speed. Since UNIX has little assembly language support, I am stuck writing an inferior version. It will still be a while before I am done and will be mainly used to try out FORTH programs that I run across in magazines or at conferences. If there is a decent version somewhere out there I would appreciate comments and hints.
wls@astrovax.UUCP (William L. Sebok) (10/09/84)
> I am currently working on a FORTH simulation in C for personal use. > The main difficulty so far is using direct memory access and management. The > more I write, the more I realize I should have used assembly language. > As is, I probably won't be able to push bytes, words, and doubles on the > same stack and still have a decent speed. Since UNIX has little > assembly language support, I am stuck writing an inferior version. This is very much my own opinion, that a Forth written in C is too slow to be of any use except as a toy for computer science classes. Forth's idea of the appearance of the world is just too different from C's for an efficient forth implementation in C. However that does not necessarily imply that all of a forth implementation should be all in assembler. Most of an implementation can (and should) be written in Forth. The problem of pushing bytes words and doubles on the same stack is a non-trivial problem in principle, if portablility is desired. This is mainly because the Forth standards have not yet recognized the existence of 32 bit machines. Mitch Bradley (sun!wmb) and I are working on proposals for standards on this issue. This involves a set of standard names for words for common operations on and conversions between objects of different sizes. A convenient size is defined as an atomic unit on the parameter stack (16 bits on a 16 bit machine, 32 bits on a 32 bit machine) and smaller items are padded on the stack to this larger unit. For example, in this proposal on my 32 bit Vax implementation, the operator W@ takes an address (4 bytes) from the stack, accesses the two byte integer pointed to by this address, and pads it with zero bytes to fill a 4 byte stack entry. The operator <W@ does the same thing only sign extends the two bytes to 4 bytes. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls