Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I'm now converting to dynclasses. To be honest, I'm not thrilled with this. What I would really prefer is a Parrot_new_p_s opcode with the runtime worrying about caching class names across sub and module boundaries.
$P0 = new "Py_int"
or some such has a considerable runtime overhead, if that is emitted as a "new_p_sc" opcode. So we probably want to reserve a certain range of PMC enums for Python, Perl, whatever. With fix assigned PMC types, the type lookup could use integer types again and type numbers aren't depending on load order of PMC extensions.
Yes, I meant the ability to do things like '$P0 = new "Py_int"'.
Could this be JITed? The mapping between string class name and assigned PMC type is constant throughout the life of the VM...
What provoked me to suggest that was a statement made in IRC yesterday that TCL is doing a find_type in every subroutine that does a new. And the knowledge that every local variable in Python and PHP is likely to be a PMC.
My concern is that if there isn't a convenient way to look up and cache these types, the "considerable runtime overhead" will still be incurred, but in ways that aren't readily ameanable to optimization by the runtime.
- Sam Ruby
