Static Languages

Andrew Whitworth wknight8111 at
Thu Feb 25 00:01:26 UTC 2010

On Wed, Feb 24, 2010 at 1:50 PM, Jon Gentle <parrot at> wrote:
> At any rate, when I talked about design philosophy, I was really talking
> about the approach taken, not the focus.  Two key points that stick out me
> are being register based and not enforcing an object model.  The latter is
> what, to me, makes parrot stand out as a VM over any other VM.  JVM, CLI,
> and all other VMs I can remember are built from the ground up with a
> globally enforced object model.  I much prefer parrot's approach that allows
> languages the choice to use the global object model or not.  It's seems very
> perl-ish.

Being register-based certainly does make Parrot stand out among other
VMs, though it is not necessarily a huge "improvement". In theory
there are some modest performance wins to be had because we can avoid
a lot of stack manipulation code. In practice, we haven't really
pushed the implementation to the limit and we still suffer from a
pretty high amount of data moving and copying. At the moment I would
call it a tie, though we will see how far we can advance the issue in
the future.

As for the object model, you are right that Parrot's is a lot more
flexible than JVM or CLI. However, our object model is still
relatively immature and a lot of work needs to be done to really make
it as flexible and robust as it needs to be. We're always looking for
help in this regard, and if you would like to get involved to start
sharing ideas I'm sure it would be very welcome. Specifically, if you
could explain the kinds of features that your project needs, that
would help us out so we can be sure to support them.

> Hopefully, this brings a little more light to my reasoning and thoughts on
> the idea.  Maybe the best way to describe my thought process right now is an
> alternate virtual instruction and register set that shares a common runtime
> with parrot.

now thats an interesting idea, and I would definitely like to discuss
it more. Ideally Parrot's internals should not depend on specific
knowledge of the opset, so you could in theory supplant a new opset
and runcore on top of the runtime.

> I did a little research into implementing FORTRAN on parrot over the
> weekend, but decided that I don't know FORTRAN enough to do anything quickly
> with it.  However, it sure sounds like a interesting and entertaining hack.

I've looked at exactly the same idea too. I would definitely try to
contribute if you started a project for it.

--Andrew Whitworth

More information about the parrot-dev mailing list