On Mon, Feb 1, 2010 at 11:17 AM, M.-A. Lemburg <m...@egenix.com> wrote: > Collin Winter wrote: >> I think this idea underestimates a) how deeply the current CPython VM >> is intertwined with the rest of the implementation, and b) the nature >> of the changes required by these separate VMs. For example, Unladen >> Swallow adds fields to the C-level structs for dicts, code objects and >> frame objects; how would those changes be pluggable? Stackless >> requires so many modifications that it is effectively a fork; how >> would those changes be pluggable? > > They wouldn't be pluggable. Such changes would have to be made > in a more general way in order to serve more than just one VM.
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 _______________________________________________ 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
