On Wed, Feb 24, 2010 at 1:50 PM, Jon Gentle <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
