Mon Aug 11 13:11:57 CEST 2008
ANS : Forth in Forth + ???
What are the necessary primtives to implement a Forth in Forth? The
problem I'm trying to solve is to simulate an on-target Forth between
full simulation and full stand-alone.
The only real primitives are
@ ! execute
Which means: memory and execution model are abstract. This works for
the standard PIC18 boot monitor, which is really nothing more than the
3 instruction Forth  together with some implemented primitives for
programming and more block transfer with less overhead.
So, let's first build a complete abstract forth machine.
What does a completely abstract ANS Forth machine look like?
* two stacks of cells (the parameter stack and R stack: >R R> R@)
* a cell array allocation mechanism (ALLOT)
From the standard document.
3.3 The Forth dictionary
Forth words are organized into a structure called the
dictionary. While the form of this structure is not specified by the
Standard, it can be described as consisting of three logical parts:
a name space, a code space, and a data space. The logical separation
of these parts does not require their physical separation.
A program shall not fetch from or store into locations outside data
space. An ambiguous condition exists if a program addresses name
space or code space.
3.3.3 Data space
Data space is the only logical area of the dictionary for which
standard words are provided to allocate and access regions of
memory. These regions are: contiguous regions, variables,
text-literal regions, input buffers, and other transient regions,
each of which is described in the following sections. A program may
read from or write into these regions unless otherwise specified.
So, '@' and '!' can _only_ access data space.
Q: The important next question is: When defining reflective words
(macros), do they have access data space at all?
No. Data space does not exist during compilation, which means that all
words that are accessible at run-time should also be simulated. This
is the only proper way to unroll the behaviour completely, and have
simulated reflection that can be TRANSPARENTLY moved to real reflection.
- write a reflective ANS Forth that can generate simulated programs
using some access to the target memory (for I/O)
- from the representation of this, extract a kernel using dependency
analysis of words. draw primitives from a library.
Q: How to represent the reflective Forth?
I'm not sure if it's useful to write this on top of Coma. The result
of reading a Forth file is a structured code graph that can be
processed to generate a Forth kernel in terms of Coma and some
Q: Where to start?
Let's port JONESFORTH. In fact, it might be a good exercise to
stick with Richard Jones's literal file, and replace the x86 assembly
with Scat code.
Actually, it can be ported to plain scheme code. Let's write it in
PLT's rs5s language.
Hmm.. it's got me completely confused again. There are some problems.
I'd like to write this on top of STC primitives, which are not
compatible with direct threaded code. Alos, the dictionary model
needs to be worked out a bit. So I need a standard model where
primitives can be plugged on top of some execution/dictionary model I
can live with. Maybe the best way is to implement one myself after
all, or figure out how to modify one of the portable ones.
It doesn't look like JONESFORTH is a good starting point. Going to
remove it from the darcs archive.
I need a different set of primitives.. Maybe eForth is the way to
go after all?
I found a link on comp.lang.forth about this. This brings me back
to taygeta MAF which is what I was looking for actually.
EDIT: One night of sleep later, I think effort is best spent
elsewhere. The essential problem is that dictionary layout and
threading model need to be abstracted. If the Forth has to run on a
Flash controller, Flash programming needs to be in there too.. This
is already a large part of the interpreter.