Python/Pirate status
Sam Ruby
pass is defined as producing the exact same output as CPython produces
with the same input files.
These python specific pmcs were initally clones of perl specific PMCs,
with just enough added functionality (example: repr methods) to make
them work, and essentially hardwiring in PARROT_PYTHON_MODE in these
PMCs. Everything works without the "--python" flag, including
generators. (In fact, I suspect that generators won't work with the
--python flag).
Once this was done, I then gutted each pmc, and then incrementally added
back in only those methods that were required to pass the unit tests.
This forced me to do a code review, and will help to identify test
coverage holes. My feeling is that the smaller set of PMCs, backed by
test cases, will be easier to refactor and improve on.
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.
Once this is done, I'll commit the classes to the parrot cvs, and then
commit the corresponding changes to the pirate cvs.
After that, there are a number of directions I want to head. I want to
refactor bits of Pirate into exploiting methods that are attached to a
singleton builtin object (example: range). I want to build test cases
to cover every exposed method on every object (an example for int is
attached). I want to pass the CPython test suite. And pass the
parrot/languages/python/t/pie tests.
- Sam Ruby
Leopold Toetsch
> 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.
> - Sam Ruby
leo
Sam Ruby
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
Leopold Toetsch
> 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...
Not really or not easily. Fastest is to have type enum numbers. Which
needs reserved ranges for not yet loaded extensions.
> 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.
Well, if only one set of PMC types is used and you control program
initialization, it's not too hard, to probe Parrot for the next PMC type
number. Then the compiler can emit the "load_bytecode" ops on top and
use type numbers.
That doesn't work, if the library loading isn't always using the same
sequence, of course.
> 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.
Yes.
> - Sam Ruby
leo