[Python-Dev] Parrot -- should life imitate satire?

[Jeremy Hylton]

>>>>> "AMK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes:

  AMK> On Mon, Jul 30, 2001 at 04:16:49PM -0400, Guido van Rossum
  AMK> wrote:
  >> impact on reusability of the runtime.  The bytecode engine cannot
  >> be considered independent from the rest of the runtime.

  AMK> If you must have a portable bytecode format, why not use the
  AMK> JVM?  Perhaps it's not optimal, but it works reasonably well,
  AMK> has a few reasonably complete free implementations that are
  AMK> mostly strangling due to lack of manpower, has some support in
  AMK> GCC 3.0, and is actually deployed in browsers and on people's
  AMK> systems *right now*.

I'm not sure I understand the suggestion.  The JVM defines an
instruction set, but it also defines an entire runtime, right?  You've
got to live with the JVM's implementation of threads, garbage
collection, etc.  For the case of Python, that sounds a lot like
abandoning CPython and using JPython instead.

Or would you suggest using the instruction set but nothing else from
the JVM?  I'm not sure that there would be much advantage there.  If
we had a JVM implementation designed to support Python, there would be
no need to implement most of the opcodes.  We'd only need getstatic
and invokevirtual <0.2 wink>.  The typed opcodes (int, float, etc.)
would never be used.

The problem seems to be that the VM ties up a bunch of other issues
with the bytecode.  Python's VM is intimiately tied up with:

    - reference counting: each opcode knows when to INCREF and when to
      DECREF

    - threads: the global interpreter lock is managed outside the
      bytecode by the "Do periodic things" code.

    - object model: BINARY_ADD knows how to special case ints and what
      method to call to dispatch on all other objects

Unless the bytecode is very low level, you buy a lot more than some
instructions when you buy an instruction set.

Jeremy