Hi Collin, Thanks for the useful links.
I think that superinstructions require a bit more work, because they aren't just opcode arguments rearrangement. For example, in wpython 1.1 (that I'll release next month) I've introduced a CALL_SUB opcode to handle all kind of function types, so the 2 words pack together: - the opcode (CALL_SUB); - the function type and flags (normal, VAR, KW, procedure); - the number of arguments; - the number of keywords arguments. Superinstructions aren't intended to be a simple drop-in replacement of existing bytecodes. They can carry new ideas and implement them in a versatile and efficient way. Anyway, I don't think to continue with wpython: 1.1 will be the last version I'll release (albeit I initially have planned 1.2 and 1.3 for this year, and 2.0 for 2011) for several reasons. 2.7 is the last planned 2.x release, and once it got alpha state, there's no chance to introduce wordcodes model in it. 3.2 or later will be good candidates, but I don't want to make a new project and fork again. Forking is a waste of time and resources (I spent over 1 year of my spare time just to prove an idea). I think that wpython as a proof-of-concept have done its work, showing its potentials. If python dev community is interested, I can work on a 3.x branch, porting all optimizations I made (and many others that I've planned to implement) one step at the time, in order to carefully check and validate any change with expert people monitoring it. Cesare 2010/1/26 Collin Winter <collinwin...@google.com> > Hi Cesare, > > On Tue, Jan 26, 2010 at 12:29 AM, Cesare Di Mauro > <cesare.di.ma...@gmail.com> wrote: > > Hi Collin, > > > > One more question: is it easy to support more opcodes, or a different > opcode > > structure, in Unladen Swallow project? > > I assume you're asking about integrating WPython. Yes, adding new > opcodes to Unladen Swallow is still pretty easy. The PEP includes a > section on this, > > http://www.python.org/dev/peps/pep-3146/#experimenting-with-changes-to-python-or-cpython-bytecode > , > though it doesn't cover something more complex like converting from > bytecode to wordcode, as a purely hypothetical example ;) Let me know > if that section is unclear or needs more data. > > Converting from bytecode to wordcode should be relatively > straightforward, assuming that the arrangement of opcode arguments is > the main change. I believe the only real place you would need to > update is the JIT compiler's bytecode iterator (see > > http://code.google.com/p/unladen-swallow/source/browse/trunk/Util/PyBytecodeIterator.cc > ). > Depending on the nature of the changes, the runtime feedback system > might need to be updated, too, but it wouldn't be too difficult, and > the changes should be localized. > > 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
