Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 11:35 AM +0200 4/30/04, Leopold Toetsch wrote: >>Dan Sugalski <[EMAIL PROTECTED]> wrote: >>> If we go MMD all the way, we can skip the bytecode->C->bytecode >>> transition for MMD functions that are written in parrot bytecode, and >>> instead dispatch to them like any other sub. >> >>Not really. Or not w/o significant overhead for MMD functions >>implemented in C.
> Well... about that. It's actually easily doable with a bit of > trickery. We can either: This still doesn't work. Function calls just look different then "plain" opcodes like "add Px, Py, Pz". - it's not known, if C<add> calls a PASM subroutine - if it calls a PASM routine, registers have to be preserved. Which registers depend on the subroutine that actually gets called (ok, this information - which registers are changed by the sub - can be attached to the Sub's metadata) - every opcode that possibly branches has a significant overhead for JIT and prederefed run cores: they must recalculate their PC from a byte code PC to a run loop PC. Changing C<add> or any MMDed opcode to look like a branch is a severe performance impact for the non-overloaded case. WRT performance: You can set #define SAVE_ALL_REGS 0 in interpreter.c:912. This checks the sub's register usage and saves only needed registers, e.g. only 128 byte instead of 640 for the overload benchmark. This makes MMD calls via Parrot_runops faster then a plain function call + the check, if the operation is actually overloaded. WRT continuations: - It's highly unlikely that one would like to (ab)?use this functionality, i.e. take a continuation from an overloaded PASM and branch elsewhere. - If we really need this "feature" it is doable. On each (re)entering of the run loop a Parrot_exception is created. We would need a run loop nesting level in the continuation. When a continuation is invoked and the nesting level differs, we could longjmp(3) until we reach the old nesting level and then resume at the continuation offset. leo
