Fri Sep 19 20:11:57 CEST 2008
It's probably also easier to remove the stack argument for
primitives. If I recall this was for 'performance reasons' but I
doubt it does any good at all..
There's a problem with stack.c, which mixes 2 meanings: operations on
a stack object, and operations for Forth which should be on the VM.
This needs to be disentangled. The reason for stack/vm split is the
same as pure Coma and the ``control'' extension in Staapl.
OK... i think i got all occurences now.. was a nice trip through years
of different tricks to get at the stack arguments ;) I really need a
better PF<->C interface, based on the following ideas:
* data is always owned by the stack
* only remove arguments when done (so errors leave data intact)
got a problem.. in scheduler.pf the lists waiting-write and
waiting-read return undef the 2nd time the scheduler executes..
FIXED: the problem was a local shadowing of the s parameter used with
CHECKN and ARG0...