[Python-Dev] Why is Bytecode the way it is? (original) (raw)

Paul Prescod paul at prescod.net
Thu Jul 8 15:29:16 CEST 2004

Michael Hudson wrote:

...

Well, you'd have to have RETURNVAR as well as RETURNVALUE, or in code like return a + b you'd have to create a temporary variable and store to it. We have a limit of 256 opcodes...

First, I don't see anything wrong with temporary variables...you need to keep track of how many you use I suppose, so the compiler needs to be a little bit smarter.

Second, some opcodes seem wasted to my naive eyes. e.g. PRINT_NEWLINE or all of the in-place variants of mathematical operators.

Third, you yourself came up with a hack that would allow the same opcode to work on variables or the stack using "-1" as the variable index.

Similarly, what if BINARYADD could work directly on constants and variables? I see the virtue of using the stack for objects that do not otherwise have a name. But if a value is in a contant or variable, why not refer to it by its position in coconsts or covarnames. How would you implement this? Give BINARYADD two arguments (something no bytecode has now, btw) and treat '-1' as 'pop from the stack'? This sounds obfuscatory.

If there is anywhere in the Python implementation where you trade some "readability" for some performance (and surely there are!) then wouldn't the bytecode be the place? I mean bytecodes are byte codes. They aren't tuples of pointers to nice pretty objects. They are a list of bytes that are Python's equivalent to assembly language.

And as long as we are talking about referring to things more directly, wouldn't it be possible to refer to constants by pointer rather than indirecting through the index? You'd have to fix up pointers when you first loaded the code but only once per function. Could do. Opcode arguments are only 16 bits though, unless you use the EXTENDEDARG thingy, and then they're only 32 bits: what about 64 bit platforms?

You would have to extend the bytecode format.

Python's VM is currently a stack machine. There are arguments for making it a register machine, but if we want to do that, lets go the whole hog and not have some kind of half-assed hybrid.

I'm not really talking about a register machine either. I don't understand why you would want to copy values from a heap in "main memory" into a register still in main memory to have the bytecodes operate on them to store to a register and then back to main memory.

Perhaps we take the CPU analogy too far. Or perhaps there is something deep I misunderstand.

Paul Prescod

More information about the Python-Dev mailing list