Melvin Smith <[EMAIL PROTECTED]> wrote:
> I've asked this before: Please, someone give me an example > where a dynamic opcode lib gives us something > that a well designed set of core ops and an extension > interface does not.
Can you explain the difference? Dynamic opcode libraries are extensions to our core opcode set. Its debatable what shall be an opcode or better be a callable function. But opcodes are the primary execution parts of the VM. When speed matters, a piece of code is better a separate opcode then a function bound to some PMC.
I think we both know the difference. The ops are inlined, fast, cacheable and jitted. Extensions may not be. If an extension is pure Parrot, then it can also be jitted. The biggest overhead I see is when we have to fetch the routine through a PMC lookup, that is too slow.
Here is the crux: This isn't a VM designed for raw speed. It is dynamic and
symbolic, and optimized in the right places, but that does not mean we have
to cut corners and make it messy. I can only see justification for extending
the opcode set in the case of some weird language that has something
Parrot doesn't support. In that case, I still say the proper thing to do is patch
Parrot and include those ops in the standard distro.
Maybe what we are really debating is: What do we include in the standard Parrot distribution. The fact that ops sit in separate libs doesn't bug me so much as the idea of lots of little oplibs sitting on CPAN.
-Melvin
