Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> 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.
That could work fine for register frames, which are big anyway. OTOH
control, user, and pad stacks items are single pointers. Accessing single
items as frames isn't really optimal.
>> *Will please somebody describe all the semantics of Continuation usage.*
> 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:
That's clear. The problem is actually, how to create the continuation,
so that everything looks like a proper function call. The call
sequence of a .pcc_call maps to the creation of a continuation:
.pcc_begin
.arg x
.arg y
.create_call conti, label
.pcc_end
The return is usually a different location:
.pcc_begin
label:
.ret_from conti
.result r1
.result r2
.pcc_end
This OTOH doesn't really cover the usage of a continuation that is
passed on to a function or method call as an argument.
> 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.
Interesting idea. OTOH these register moves are really fast. C<set_p_p>
is two CPU instructions only in the (i386) JIT core.
> 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
pushp from, to
could replace all variants we now have:
pushp # 0..31
pushtopp # 16..31
pushbottomp # 0..15
That would need variable sized register frame chunks. But looking at
current memory costs of C<pushtopp> and friends, it could be a good
optimization.
leo
