2011/8/31 Terry Reedy <tjre...@udel.edu> > I find myself more comfortable with the Cesare Di Mauro's idea of expanding > to 16 bits as the code unit. His basic idea was using 2, 4, or 6 bytes > instead of 1, 3, or 6. >
It can be expanded to longer than 6 bytes opcodes, if needed. The format is designed to be flexible enough to accommodate such changes without pains. > It actually tended to save space because many ops with small ints (which > are very common) contract from 3 bytes to 2 bytes or from 9(?) (two > instructions) to 6. > It can pack up to 4 (old) opcodes into one wordcode (superinstruction). Wordcodes are designed to favor instruction "grouping". > I am sorry he was not able to followup on the initial promising results. > In a few words: lack of interest. Why spending (so much) time to a project when you see that the community is oriented towards other directions (Unladen Swallow at first, PyPy in the last period, given the substantial drop of the former)? Also, Guido seems to dislike what he finds as "hacks", and never showed interest. In WPython 1.1 I "rolled back" the "hack" that I introduced in PyObject types (a couple of fields) in 1.0 alpha, to make the code more "polished" (but with a sensible drop in the performance). But again, I saw no interest on WPython, so I decided to put a stop at it, and blocking my initial idea to go for Python 3. > The dis output was probably easier to read than the current output. > > Perhaps he made a mistake in combining the above idea with a shift from > stack to hybrid stack+register design. > > -- > Terry Jan Reedy > > As I already said, wordcodes are designed to favor "grouping". So It was quite natural to became an "hybrid" VM. Anyway, both space and performance gained from this wordcodes "property". ;) Regards Cesare
_______________________________________________ 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