2010/2/1 Collin Winter <collinwin...@google.com> > I believe these VMs would have little overlap. I cannot imagine that > Unladen Swallow's needs have much in common with Stackless's, or with > those of a hypothetical register machine to replace the current stack > machine. > > Let's consider that last example in more detail: a register machine > would require completely different bytecode. This would require > replacing the bytecode compiler, the peephole optimizer, and the > bytecode eval loop. The frame object would need to be changed to hold > the registers and a new blockstack design; the code object would have > to potentially hold a new bytecode layout. > > I suppose making all this pluggable would be possible, but I don't see > the point. This kind of experimentation is ideal for a branch: go off, > test your idea, report your findings, merge back. Let the branch be > long-lived, if need be. The Mercurial migration will make all this > easier. > > > Getting the right would certainly require a major effort, but it > > would also reduce the need to have several branches of C-based > > Python implementations. > > If such a restrictive plugin-based scheme had been available when we > began Unladen Swallow, I do not doubt that we would have ignored it > entirely. I do not like the idea of artificially tying the hands of > people trying to make CPython faster. I do not see any part of Unladen > Swallow that would have been made easier by such a scheme. If > anything, it would have made our project more difficult. > > Collin Winter
I completely agree. Working with wpython I have changed a lot of code ranging from the ASDL grammar to the eval loop, including some library module and tests (primarily the Python-based parser and the disassembly tools; module finder required work, too). I haven't changed the Python objects or the object model (except in the alpha release; then I dropped this "invasive" change), but I've added some helper functions in object.c, dict.c, etc. A pluggable VM isn't feasible because we are talking about a brand new CPython (library included), to be chosen each time. If approved, this model will limit a lot the optimizations that can be implemented to make CPython running faster. Cesare Di Mauro
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
