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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4