Path: utzoo!attcan!uunet!samsung!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.lang.forth
Subject: Forth development environments
Message-ID: <7010@pt.cs.cmu.edu>
Date: 17 Nov 89 12:26:13 GMT
Organization: Carnegie-Mellon University, CS/RI
Lines: 46

development environment for the RTX 4000.  Several
issues for Forth support have arisen, and I would
like to get inputs from the potential user community.
My primary issue of concern at this point is "where
does the outer interpreter live" for software development?
The context is support for minimal embedded systems, which
don't have their own full keyboard, CRT, or disk drive.
 
1) Outer interpreter lives on the development target
    - Traditional Forth environment (probably uses a host for
       storing source code and KEY/EMIT support)
    - Dictionary and Forth compiler live on target too, causing
       10% to 20% system size increase.  This *may* mean that
       the target must have a row of extra memory chips not
       populated on production systems (wasted board space).
    - If a full Forth system is shipped with the product, there
       may be (possibly unfounded) fears that the user can "take over"
       the machine, especially in financial transaction systems.
       There are also configuration management questions if the
       system code can be modified by the user.
    - Very portable between hosts, since little code executes on the host.
 
2) Outer interpreter lives on the development host.
    - Continuation with existing RTXDS software environment from
        the RTX 2000.
    - Classic metacompilation problems, especially confusing to
        newcomers to Forth.  Defining words are especially tough.
 
3) Outer interpreter lives on the development host, but
   all efforts are made to make it appear to live on the target
    - If indistinguishable from a system where the outer interpreter
       lives on the target, then you get similar capability without
       the increased memory costs on the target.
    - Can this be done seamlessly? Or will it turn out to be too
       grubby to be worthwhile?
 
So, what do you think?  Actually, this is probably a seed for a discussion
on preferred development environments for any Forth system
(e.g. metacompiled vs. using an assembler for initial bootstrap
development) as well.
 
  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
Senior Scientist at Harris Semiconductor.
I don't speak for them, and they don't speak for me.