[<<][packetforth][>>][..]
Fri Sep 19 20:11:57 CEST 2008

2 arguments

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...




[Reply][About]
[<<][packetforth][>>][..]