forth to run on a UNIX machine

[William L. Sebok]

>   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