At 10:40 AM +0200 6/8/02, Jerome Vouillon wrote:
>On Fri, Jun 07, 2002 at 01:50:27AM -0400, Dan Sugalski wrote:
>> So, in total, we need:
>>
>> *) Original routine entry point
>> *) Current routine entry point
>> *) Native/bytecode flag
>> *) Opcode table
>> *) Global namespace chain
>> *) "default" lexical scope
>> *) All the register sets
>> *) All the stack frames
>>
>> Needless to say, we don't want all subs to switch this in--we want
>> perl 6 *faster* than perl 5, not slower. Because of this, it seems to
>> make sense to have multiple PMCs that have specialized knowledge of
>> how to invoke themselves, as well as a vtable entry for invocation.
>
>Making a function call via a vtable entry does not seems cheap to me,
>especially when you consider that in the common case, you only need to
>save the return address and jump to the sub entry point.
>(Switching the global namespace chain and the lexical scope does not
>cost anything: it just means passing the closure as an additional
>argument to the sub.)
Indirect function calls will take maybe 50 cycles, so I'm not worried
about their time. Compared to perl 5, that's fast. There's more to it
than that, though, on sub entry. Getting the right environment is
more than just passing in a closure.
>A continuation can be invoked just like any other function. The first
>opcode of its body can then switch the stack frames. (The register do
>not need to be switched if we specify that callcc does not preserve
>them.)
The thing with continuations is that the code we're invoking won't
know its a continuation. That information's kept as metadata in the
sub PMC. (And we do need to restore the registers, otherwise we're
going to see a lot of stack pushing and popping every time we take a
continuation, and I don't know that it's worth it)
>Switching to native call and switching the opcode table is probably
>the trickiest point. Maybe we can use a stub: the body of the sub
>would be a special opcode that performs the switch, executes the sub,
>and returns. I don't think this is signifiantly slower than what you
>are proposing. And it may be possible to inline the stub body.
I'm proposing we abstract it all away and embed all the code in the
sub invocation vtable entry. That way the code can be a
straight-line, specialized chunk that does exactly what's needed with
no twiddling about with conditionals or whatnot.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
