erempel@sirius.UVic.CA (Evan Rempel) (05/03/91)
Forth: A different look at the standard
Before I start, I would like to say that I have not read the
BASIS15 (or any others for that matter), but believe that I am not
saying anything that detracts from its design.
Forth has been defined differently by different people over
the last twenty years, but the definition that I think fits most
appropriately is that of a virtual central processing unit (CPU),
with Forth as its assembly language if you will. This virtual CPU
has been implemented directly in silicone (Harris RTX2000, Novix
NC4016, Silicon Composers SC32 (John Hopkins) are some of them),
and many more have implemented this virtual CPU in software (Fig-
Forth, PolyForth, and F83 are just a few).
From this definition it is conceivable (not necessarily
desirable) to produce a compiler for any language that compiles to
the Forth CPU assembly language instruction set. That is to say,
that Forth for these machines is like assembly language, and a C
compiler could be written to compile C to Forth. Pascal, Fortran,
Cobol etc. could also be implemented. The main thing is that they
all use the same virtual CPU, and as a result, are all portable at
the assembly language (Forth in this case) level.
I have no preference for the direction that the ANS Forth
takes. These things are like adding a macro compiler to an
assembler. One that handles strings, data type etc. These things
are all great, and need to be placed into the standard, but they do
not affect the virtual CPU. They do not give any great power to the
user, only a set of library routines that can be called upon to do
the desired work. Thank goodness for these efforts, or Forth would
*really* be standing still.
What I am trying to get at here is that the virtual CPU is a
good place to start, but it does not cover all of the ground that
the application programmer is going to use. If you are going to
implement a virtual CPU, why not go the extra ten yards and
implement an entire virtual machine.
I have been working on this for a while, and after
specializing in real-time operating systems for the past six years
and programming in Forth for eight years I believe that I have a
viable solution to this approach.
I recognize that the application programmer can perform many
of the tasks directly in the application program. Some are
difficult, some are not possible, and some are not necessary for a
single virtual CPU (VCPU), or where multitasking is not required.
There have been many papers written on the greater problem
solving power of a concurrent (multitasking) programming approach.
There is no question in my mind that a standardized multiple VCPU
machine is another approach to creating a more powerful Forth. This
does not, in any way, prevent the ANS Forth from being implemented
on this virtual machine.
A small set of things that are offered in such a system are;
- preemptive multitasking
- priorized tasks
- high level interrupt programming (can be done in Forth)
- Totally ROMable, including application programs.
- smaller execution code than F83
- considerably faster execution that F83 (faster VCPU
design)
- dynamic memory allocation (allows for data structures to
be built)
- time keeping functions (necessary for data
communications)
- interprocess communications (semaphores, mail boxes,
shared data space etc.)
I would like to have some feedback on such an approach,
hopefully positive, but I can handle a small amount of criticism.
I am very interested in how single board manufacturers view such a
system, and if there is any genuine interest out there for such a
system. Feel free to use the phone or send paper mail, any response
will be welcome. I am very willing to discuss system
specifications, without giving away anything that is potentially
marketable.
________________________________________________________________
____ ____ _ _
| _ \ | __|| \ / | Evan Rempel
| |/ / | |_ | \/ | erempel@sirius.UVic.CA
| < | _| | \ / | Box 458
| |\ \ | |__ | |\/| | Sooke, British Columbia
|_| \_\|____||_| |_| Canada V0S 1N0
______________________ (604) 646-2890
Doing the impossible, because I don't know it can't be done.
________________________________________________________________