LLL

[Russell Y. Webb]

>> 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.
>   This is an interesting point. But I think we should keep things as
>modular as possible, and make the threading method parametrizable.
>See how even caml-light (a bytecoded ML system) already allows two
>bytecode threading methods. We can do much better, and allow more of them.

I don't know anything about caml-light code or even where to find a
discription of the code format, but why can't a byte code processor be
expandable.  All you do is define a standard code set of instructions with
one threading method.  Then undefined codes call external replaceable
modules.  I use this technique on the Mac.  Of course external code is not
the simplest OS feature to implement, but one you have it...

>   Thus, let's not discard this suggestion, but not hardwire such
>behavior in our code. Moreover, there already are lots of refinements
>possible; for example, on word-addressable machines with many registers,
>it might be useful to pack instructions by words, with 0 being NOP, so
>instructions with word parameter are faster, etc; or there can be two
>pointers, one for byte-aligned things, one for word-aligned ones...

I realize some of the MISC chips are an exeption, but doesn't a byte
processor with prefetch amount to a pack word machine (if the word is
n-bytes).  I think it is safe to say that the byte is the smallest word
size that is commonly supported and most machines are n-byte machines.

Russ Webb