develooper Front page | perl.perl6.internals | Postings from September 2001

Re: An overview of the Parrot interpreter

Thread Previous | Thread Next
From:
Dan Sugalski
Date:
September 6, 2001 09:55
Subject:
Re: An overview of the Parrot interpreter
Message ID:
5.1.0.14.2.20010906123854.02139b30@pop.sidhe.org
(Firstly, I'd say trust Nick's expertise--he has spent a good-sized chunk 
of his career doing software simulations of CPUs, and knows whereof he 
speaks, both in terms of software running on hardware and software running 
on software)

At 05:33 PM 9/6/2001 +0200, Paolo Molaro wrote:
>I believe that a stack-based machine will have roughly the same
>performance when interpreted as a register-based machine, but
>it easily allows to take a step further and JIT compile the bytecode
>to machine code. If we are going to execute low-level opcodes,
>no matter what architecture you choose for the interpreter,
>JIT code runs faster:-)

On x86 machines. Maybe. I think you both underestimate

> > is a pain.) Explicit stack ops are going to give them indigestion.
> > The P-III+ model is that most things are "on the C stack" i.e. offsets
> > from the few "base" registers. The hardware then "aliases" those offsets
> > into its real registers. I don't think Parrot's register files will give
> > it much trouble, but throwing away the right inc/dec-of-pointer ops that
> > a stack machine implies will (there are obviously HW special cases for 
> x86's
>
>With the difference that the registers are malloc()ed while the eval
>stack in a stack machine is in the actual cpu stack.

Absolutely *not*. No way is the eval stack going to be the real CPU stack. 
That puts nasty artificial limits, or massive memory requirements, on the 
interpreter. It also makes GC a major pain in the neck, since it means 
walking the stack and trying to extract real variable usage info. Bletch. 
Even if perl 6 goes the stack route, we won't be using the system stack.

The registers will be from heap memory, but that's not a problem in and of 
itself. Cache lines are cache lines.

Anyway, I think the point's moot for now. Parrot's register based unless 
either performance is substandard and demonstrably because of the register 
architecture, or because I get bussed and my successor's more comfortable 
with stacks. (The first is certainly possible)

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About