Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!samsung!caesar.cs.montana.edu!ogccse!blake!unicorn!n8243274
From: n8243274@unicorn.WWU.EDU (steven l. odegard)
Newsgroups: comp.lang.forth
Subject: Forth in MODULA-2
Summary: Interactive forth definition in Modula-2
Keywords: FORTH, MODULA-2
Message-ID: <328@unicorn.WWU.EDU>
Date: 15 Nov 89 23:27:55 GMT
Reply-To: 8243274@nessie.WWU.EDU (steven l. odegard)
Followup-To: comp.lang.forth
Organization: Western Washington Univ, Bellingham, WA
Lines: 57

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.