Tue May 26 17:03:38 CEST 2009
What would be the most useful way to incorporate standard Forth into
the project? The reason you'd want standard Forth is to use already
existing Forth code.
There are several problems that prevent standard Forth use at this
moment. The most severe ones are:
* 8-bit cell size -> some intermediate layer that implements 16-bit
access is necessary.
* non-standard parser.
The latter isn't such a problem. Once it's clear what kind of VM we
want for the 16-bit forth, a self-hosted Forth should be
bootstrappable with the already existing parser.
The question is then: what kind of VM. A subroutine threaded 16-bit
VM would work better with the already existing architecture, but an
indirect threaded Forth is easier to implement in a machine-
independent way. Interoperability is more important than reduced
implementation complexity so let's start by creating a subroutine
threaded compiler in Forth.
To write a self-hosting compiler, the form of the dictionary should be
I need at least this:
[ link | name | CT | XT ]
Where the dictionary either contains a pointer to the code, or the
code inlined. Probably a pointer is better since then the dictionary
could be stored somewhere else (and stripped).
So what about this:
- FIND returns a dictionary record
- REC>XT returns the interpretation semantics
- REC>CT returns the compilation semantics
A dictionary structure is then
[ link | CT | XT | name ] where the name is a padded pascal string.
Do strings have a special representation?
Also, I want a Forth with space-safe tail calls.
Looks like the most difficult part is string comparison. I wouldn't
know how to do that without a huge amount of stack shuffling (pointers
and sizes). Let's see how this is usually done.
I'm starting to think that writing a self-hosted Forth that needs to
be bootstrapped isn't such a good approach. It's probably easier to
write it top-down and just bootstrap the dictionary.