LLL

[Francois-Rene Rideau]

> I haven't been following Tunes for long, so please forgive any ignorance of
> what has been said already that I exibit.
   No problem. However, perhaps you could read the TUNES WWW pages and
send feedback...


> 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.
After real-life simulation, we can make some definitive choice, not before.
Remember how Jeff Fox wrote forty compilers for the MuP21 to find the best
one. 
   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...

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"