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

["Martin v. Löwis"]

Paul Prescod wrote:
> 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.

There is something wrong with it: it is painful to implement.

Just think of the stack as a set of temporary variables, and
RETURN_VALUE becomes the same thing as RETURN_VAR.

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

Yes, that is correct. However, even if that was cleaned-up (which is
difficult and time-consuming to do), there still would be only 256
opcodes (at some point, there were only 128 of them).

> 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.

Might be. You are mixing questions now: are you asking "why is it the
way it is?" or "can we please change it?"

It is the way it is because a stack machine is the easiest thing to
implement and source-review.

> 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.

Yes. That makes bugs in the implementation most difficult to track down,
and obviousness in the implementation a high priority, even more than
performance: what good is a fast but incorrect implementation of the
language?

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

Most certainly. This stuff is *way*, *extremely* more difficult to write
than it is to read. Just try and see for yourself. The number one reason
that possible changes have not been carried out is that they are so 
difficult to implement even if they are straight-forward to talk about.
The number two reason is that those changes don't actually show the
advantages that they theoretically should show, because the abstract
model abstracts too much of the real computer hardware.

Regards,
Martin