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