koopman@a.gp.cs.cmu.edu (Philip Koopman) (11/17/89)
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.toma@tekgvs.LABS.TEK.COM (Tom Almy) (11/21/89)
In article <7010@pt.cs.cmu.edu> koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: >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 >2) Outer interpreter lives on the development host. >3) Outer interpreter lives on the development host, but > all efforts are made to make it appear to live on the target Well my batch Forth compiler, CFORTH, is almost a case 3. - Colon definitions (which compile into machine code), code words, and all data are located in the target image. - Headers do not go into the target image, which prohibits case 1 operation. - During compilation, the interpreter runs, and you get roughly 83 Standard operation: tick works, @ and ! access the target image memory. You cannot execute colon definitons and code words in the target, but can create colon definitions that execute in the host. - DOES> and ;CODE are supported. The portion of the definition before the DOES> or ;CODE compiles into the host image (defining words can't be executed at "runtime" anyway), and the portion afterwards compiles into the target image. An attempt to execute a defined word returns only the address of its data (much like ticking would do). - The scheme runs quite cleanly, and with seemingly little confusion. My favorite "trick" is to write the Byte (sieve) benchmark so that it runs at compile time and prints out the answer at run time. Blazingly fast execution! Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply -- CFORTH is a commercial product.