n8243274@unicorn.WWU.EDU (steven l. odegard) (11/16/89)
I had worked about six months of spare time on Forth in Modula-2, on the
university VAX-8600. I gave up the project for the following reasons
(1) Lack of Modula-2 language support: No documentation was available on
how to establish exception handlers via Modula-2. Thus an error like
entering
> 0 @
would generate an exception and halt the program rather than return
to the outer-interpreter, resulting in a loss of all defined words.
I had alleviated some of the problem by coding a "save" function
in Modula-2 to dump the 'core' memory to a disk file, with a "retrieve"
function corresponding.
(2) Lack of available documentation in Forth: Since Forth was designed for
16 bit machines, and the Vax-8600 was a 32 bit machine, it was necessary
to reconfigure much of the standard instruction set to work for 32 bit
words. It was also necessary to define many words on attempting to
'bootstrap' much of the system together. This later proved too cumbersome.
I had begun with the instructions in the set from the Novix 4004 chip
and coded core routines of the outer-interpreter in Modula-2, with the
rest bootstrapped in Forth. Though this may sound elegant, minimal Forth
was not at all easy to work with, and proved very difficult to modify.
Loeliger's book, _Threaded Interpretretive Languagues_, was the the
principle design tool, but it was based on the fig-Forth model. Forth
83 doesn't have the designing word <BUILDS, and I have not found satisfactory
explnation of how defining words are constructed in Forth 83. Furthermore,
though lists of 83 'required' words are available, it is not at all clear
which of those can easily be coded in terms of other words.
(3) Resulting system was excruciatingly slow. Efficiency of operation was
not a design goal, but the end result was disappointingly inefficient.
A few comments:
(4) The Forth system was not designed around terminal IO: The standard input
and output system employed on a terminal-mainframe requires that a
carriage return be entered to 'send' the entered line to the calling
program. This is also echoed to the terminal, so where a session shold
appear as:
3 4 + . <cr> 7 OK
it would appear instead as
-> 3 4 + . <cr>
7 ->
The dash greater-than sign was simply my prompt for input.
(5) I originally designed the system to be able to push and pop strings
from the stack as well as 32-bit numbers, in the first version. This
required careful stack control, but made it easier to build the outer
interpreter with a minimum of design tools. I was in the process of
redesigning the system without strings-on-the-stack controls, but
it proved too difficult and much of the system must be re-built.
I am interested in extending the project, but the first two problems have
proven unresolvable with what resources I have available. It was originally
designed as a debugging tool for Modula-2 programs, but with the improvements
in the DEC debugger, this became superfulous.