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.
If the JIT structure makes it untenable, it doesn't work, and that's fine. I don't think it has to be quite as bad as it is now, but on the other hand the performance hit in general needed to make this work better is probably not worth it.
Something to keep in mind once we get more of the base PMC types implemented, and have more of an idea how much of the MMD code ends up being bytecode vs C.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
