[Python-Dev] Why is Bytecode the way it is? (original) (raw)
Jeremy Hylton jhylton at gmail.com
Thu Jul 8 16:29:25 CEST 2004
- Previous message: [Python-Dev] Why is Bytecode the way it is?
- Next message: [Python-Dev] Why is Bytecode the way it is?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Why is Bytecode the way it is?
- Next message: [Python-Dev] Why is Bytecode the way it is?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]