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

Jeremy Hylton jhylton at gmail.com
Thu Jul 8 16:29:25 CEST 2004


On Thu, 08 Jul 2004 07:14:42 -0700, Paul Prescod <paul at prescod.net> wrote:
> I'm really not even proposing a change to Python as much as trying to
> understand why it is the way it is. I can see how a stack is helpful for
> evaluating deeply nested expressions (although temporary variables seems
> another good valid approach). I just don't see the payoff for shuffling
> variables from locals onto the stack and back into the locals table.

A stack machine is simple to implement and simple to understand.  It's
also a classic approach; lots of language implementations have
stack-based virtual machines.  Why is it the way it is?  Because it
is.  That is, it's an obvious choice for implementing a language.

It doesn't need to be that way.  Lua and Parrot, to pick to recent
examples, have register-based virtual machines.  Roberto Ierusalimschy
gave a nice talk on Lua 5 at LL3.  Lua 4 had a stack-based virtual
machine, and Lua 5 has a register-based virtual machine.  The
benchmarks he reported there showed a 4-16% speedup largely
attributable to the new virtual machine.  He also had some instructive
closing comments:

Compiler for register-based *machine* is more complex
 - needs some primitive optimizations to use registers
Interpreter for register-based *machine* is more complex
 - needs to decode instructions
Requirements
 - no more than 256 local variables and temporaries
Main gains:
 - avoid moves of local variables and constants
 - fewer instructions per task
 - potential gain with CSE optimizations

Slides are here:
http://www.inf.puc-rio.br/~roberto/talks/lua-ll3.pdf

Jeremy


More information about the Python-Dev mailing list