Differences between Release 2 and Release 3

Gray runs now on Tile Release 2.1. It uses Tile's new "source" and
"line" words for displaying error locations. Therefore it does not
work on Release 1 of Tile.
Some portability bugs have been removed.

Differences between Release 1 and Release 2

Gray now runs on computers with memory alignment restrictions, too.
Tile Release 2 is now supported, it needs porting to run on Tile
Release 1.
Changed "(compile)" into "compile," (ANSI).
No bugs were reported. Therefore they are still there.

******************************************************************
* These notes by mhx, Tue July 27, 1993. Conversion to ANS Forth *

Translation
-----------
The "conversion" was simple. I deleted all Tile specific stuff and assumed
the code was to run on an ANS Forth with the Core Extensions, Double-Number,
Exception, Search-Order and File-Access word sets.  That meant a lot of
prelude code could be deleted.

Problems encountered
--------------------
The only real problems were the use of vocabularies in mini.frt, and
use of EXECUTE while compiling (STATE @ not zero), also in mini.frt. Some
alignment problems were fixed. The use of COMPILE and [COMPILE] needed
careful attention.

In general, the code was changed when it either was non-portable or when
using an ANS Forth feature made the source file shorter.

The code was tested on tForth vsn 1.1 (T8 transputer) and iForth vsn 1.01
(i386/486). These are optimizing 32-bit subroutine-threaded systems,
internally quite unlike the direct/indirect threaders expected by the
original code. The transputer for instance *needs* aligned addresses, and
iForth runs in protected mode, catching incorrectly initialized variables and
structures.  Now the segmentation faults and hangups have stopped I'm quite
sure that porting to other environments is trivial.  
Don't quote me on that.

Features added
--------------
I put a small routine in calc.frt and mini.frt that lets ? use any input device
transparently. It was using KEY .

Errors of the parser are now illustrated with the full source text. The
method used is thought to be portable. It costs some memory however.

The fact that a large return stack size is needed (360 cells or more) is 
an environmental dependency. It is now checked for with:  

 s" return-stack-cells" environment? 
    [if] 360 < [if] cr .( Return stack too small) abort [then] 
  [else] cr .( What's a return stack?)
  [then]

There is no way a standard program can enlarge the return stack. 
I observed a stack depth of over 70 cells in calc.frt and 270 in oberon.frt.
The code in setstack.frt may help for some systems.
