Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> You seem to be mixing up different issues with that statement. Using
>>> plain Continuation PMCs for returning just from subroutines was dead
>>> slow, w or w/o COWed stacks.
>
>> But when a Continuation is simply a collection of pointers to the tops
>> of the various stacks (and I really do think it should include P1 in
>> that list...) will it really be that slow? I'm surprised.
>
> You are missing object creation overhead. P1 and P2 are in the saved
> P-register frame.
>
> And finally: I really don't know, if a Continuation needs just pointers
> to the stacks (and to which) or (COWed) copies (to which).
If a 'single object per stack frame' approah, the continuation only
needs pointers to the various stacktops. In fact all that anything will
need for dealing with such stacks is a pointer to their current
stacktop.
> *Will please somebody describe all the semantics of Continuation usage.*
A Continuation is a closure over the call chain, and the various stacks
in the context. Someone proposed in email that, actually, a
continuation should close over everything but the parameter
registers. Consider the following:
savetop
$P0 = newcont target
store_global "theCont", $P0
target:
restoretop
here:
...
When the continuation is invoked using, say, "cont("Result1", 2, "bibble")
the registers and user stacks should look exactly the same as if you
had just returned from a normal function call that looked like:
a_function_call()
here:
ie: P1 and P2 would be untouched, as would the high registers, and the
various parameter/return registers would be populated with the returned
values.
Given the way that the stack stuff works, I wonder if there's a case
for rejigging the calling conventions so that the control registers
(current continuation, self, (methodName?)) are contiguous with the
user registers. If we made P15 the current object, P14 the current
continuation, and S15 the methodname, then savetop could include them
efficiently without IMCC having to do 'set P20 = P1' at the start of
every sub that makes a function call.
If IMCC were then to always allocate 'user' register in ascending order
from 16, presumably it'd be possible to introduce a new op:
saverangep 14, 20
saverangei 16, 18
...
Along with associated
restorerangep <start>, <count>
(or should that be
restorerangep <start>, <end>
Thoughts?
