S. entry on Dan's blog: Registers vs stacks for interpreter design. It's on this page: http://www.sidhe.org/~dan/blog/archives/2003_05.html
klaas-jan ----- Original Message ----- From: "Brent Dax" <[EMAIL PROTECTED]> To: "'Tom Locke'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, August 21, 2003 6:40 PM Subject: RE: Registers vs. Stack > Dan should really be answering this, but I'll try... > > Tom Locke: > # The FAQ briefly mentions: > # > # we're already running with a faster opcode dispatch > # than [Perl, Python, and Ruby] are, and having registers just > # decreases the amount of stack thrash we get. > # > # Can I for one ask for some more detail? > > Pushing and popping values off a stack--especially the fairly > complicated stacks Parrot uses (and needs)--is an expensive operation; > by having registers, we avoid the expense. The speed hit from the stack > operations would negate much of our advantage over those other > languages. That's pretty much all we're saying there. > > As I remember, the decision to use registers was based on a few things: > > 1. Speed. > a. The above: Register accesses are faster than stack > accesses, > in several significant ways. > > b. Fewer opcodes: Using registers means less > pushing/popping, > which means that opcode dispatch is less critical and > ops > that actually *do* stuff will stay in the cache > longer. > > 2. Less bytecode: Any way you slice it, "print X" is smaller on > disk than "push X, print". > > 3. Optimization: Optimizing register-based code is a problem > that's > been heavily studied for decades. We can leverage all that > knowledge to make Parrot bytecode run faster. > > 4. Ease of hand hacking: It's easier to hand-write and > hand-debug > register-based assembler than stack-based assembler. This > isn't > that big an issue, but it is a factor. > > Basically it comes down to this: Register architectures have some Hard > Problems, but once they're overcome the code will run faster. Stack > architectures have fewer Hard Problems, but run slower. > > All things considered, we'd rather tackle a few Hard Problems than run > slower. > > --Brent Dax <[EMAIL PROTECTED]> > Perl and Parrot hacker > > "Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna > set myself on fire to prove it." > >
