Mon Dec 4 10:55:51 EST 2006

threading model

why do i want to change the threading model to something like
subroutine threading?

-> return addresses and XT = same
-> make normal lists executable
-> easier tail calls: literal/execute and jump/call is determined by
   atom type: 'execute' bit.
-> the general case: can only look back at the last atom: compilation
   using standard forth methods is problematic using the current code
   threading model and requires a lot of hacks (like the sentinel).

other explanations:

-> there already is a type system: this can easily be modified to
   provide 'executable' bits.
-> good opportunity to clean up the interpreter guts.

so, how would this work?

-> ordinary atoms are transferred to the data stack
-> primitives are executed if they contain an 'execute' bit
-> atom pointers are called if they contain an 'execute' and 'call'
   bit, and are jumped to if they have the call bit zero.

progress log

* changed all types to LIT(type) which reserves two executable bits.
* control flow words do not change, since they take an address argument

* 'compile,' maps XT -> executable code

let's see.  i would like to do this gently: install all words to have
both threading models, then switch from one to the other by redefining
a couple of words. this is an interesting exercise: how to write a
forth largely independent from the threading model, but keep it fast?

in the pf case it might not be possible because not being able to look
back in the code thread complicates things: changing the last atom in
place is no problem, but changing jump targets is. maybe this is the
real reason why i want to change the threading model.

at this point, i cannot see the big picture, so i need to go one error
at a time, breaking things and work from there. commit now.

what i need is:

atom -> CT
XT   -> CT

CT   -> compiled code (execute)

now, in the new model, an XT is an atom pointer with CALL+EXECUTE bits

primitives that read from the instruction stream (vm->ip) or the word
body (vm->current) could maybe be incorporated as opcodes?

bottom line here again is to not implement similar mechanisms with
different tools: there is already a type system, so all 'routing'
should use this instead of a second approach (here: having things look
ahead). half baked, hard to express.