Re: Python/Pirate status

Leopold Toetsch wrote:

> Sam Ruby <rubys@xxxxxxxxxxxxxxxx> 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