LLL

[Russell Y. Webb]

>    Ok. So if no one has any objection,
>let's start with ANS FORTH as the basis for our LLL.
>*BUT*, do not use FORTH-specific meta-words and I/O words,
>and instead study how we could achieve something more compatible
>with extending the LLL toward a HLL.
>    For instance, let's remove the builtin word parser of FORTH,
>and allow people to use any syntactic analyser instead;
>let's allow people to define *contexts* instead of the vocabulary hack.

I haven't been following Tunes for long, so please forgive any ignorance of
what has been said already that I exibit.

The above constraints could be realized by a byte coded kernel which
implements all the desired Forth words as byte instructions.  This approach
may introduce a undesirable layer of software, but has the advantage of
beening easily coded in C ( for(;;) { (*jumparray[ ip++ ])(); } ) and
allowing optimization to be done on a per platform basis without effective
compatability.

The performance of such systems can be quite high expecially in a cached
environment.  I have written such a processor which includes preemptive
tasking and fair high level access to files, graphics, etc.  My system is
more of a application environment, so I haven't really done any thinking
about the requirements of an OS (in fact I'm fairly ignorant in that area).
I'd be glad to share my experience with byte processors though including:
micro-interpreters, memory protection, message passing, tasking, typable
byte code, context support, micro-compilers, cross platform binaries, high
level support, and external shared libaries.

Russ Webb