[Python-Dev] Why is Bytecode the way it is?

[Paul Prescod]

Michael Hudson wrote:

>...
> 
> Well, you'd have to have RETURN_VAR *as well* as RETURN_VALUE, 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 BINARY_ADD 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 co_consts or co_varnames.
> 
> How would you implement this?  Give BINARY_ADD 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 EXTENDED_ARG 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