Parrot/Cardinal Mini-Interview

This is the second week of my break from the serial rubinius interview, and it's time for another piece on parrot and cardinal. Is there any interest in making this into a second (for me, third overall) serial interview? I'd love to do it if there's enough interest.

This week, I'm talking to Kevin Tew (who I interviewed a while ago). In addition to some general information about his Cardinal and Parrot plans, he also gives us his take on VMs supporting multiple languages and register based VMs.

---

Kevin, now that you're past the current round of heavy lifting involved in school, you've gotten back into Cardinal and Parrot work. Can you tell us a bit about what you've been working on and what's next on your plate?

Kevin: For those who don't know me, I'm a language junkie. I really enjoy working on the low level guts of virtual machines. Lately in Parrot, I have been working on the portion of PIR calling conventions that interface between PIR (parrot high-level assembly language) and C.

Working on Parrot has been an exercise in focus for me. Once you understand the beginnings of how languages, interpreters, and virtual machines work, it is very tempting to start/invent your own language/VM. Working on an existing language/vm project may not be as glamorous as starting your own but for me, choosing to work on Parrot has been very rewarding.

I've spent my most recent Parrot time cage cleaning inter_call.c, which is where Parrot's calling convention and subroutine argument handling code lives.

The cleanup was in preparation for adding PMETHOD support to PMCs. For those that don't know Parrot PMCs are a pseudo C++ objects, implemented in C, upon which much of parrot is build. PMETHODs allow PMC methods, which are written in C, to support the full Parrot Calling Conventions that are available to Parrot Intermediate Representation (PIR, Parrot Assembly). Examples of PIR's enhanced calling capabilities include: optional arguments, named arguments, optional named arguments, slurpy arguments,slurpy named arguments, and array flattening.

What is next on my plate? I'd like to start working on the Parrot Object System. I noticed this past week in Parrot's weekly status meeting that Allison Randal has started working on ParrotBase based on Leo Toetsch CStruct ideas. I better dig in before I get left behind. I started implementing Stevan Little's Class::MOP (Meta Object Protocol) in C PMC's which he of course borrowed from Common Lisp. I soon realized that I wanted full calling convention support in C PMCs so I backtracked and created PMETHODS.

One of the knocks against Parrot is that it's a VM for many languages. It looks like the JVM and rubinius are headed down that road too (to some degree). How does hosting multiple languages help or hurt a VM?

Kevin: Writing a VM for multiple languages is certainly a challenge. The only other comparable VM I can think of that set out to be a VM for multiple languages would be Microsoft's CLR.

Microsoft built the CLR specifically with C# and C++ in mind. VB.NET is also becoming a mature language that is stretching the CLR design. Parrot's multiple language support is a development tactic that has shaped and insured the robustness of Parrot's implemented features. Building a VM, targeted by a spectrum of languages, requires Parrot designers to survey and research how each languages might use or pervert the VM feature in question. While the cost is substantial, I believe it is well worth the price.

Stating multiple language support as a prime object keeps Parrot designers and implementers honest. Corner cutting bits back pretty fast on the Parrot project.

Another knock is that Parrot is register based. Why don't you think this is a problem? (I also asked Dan Sugalski about this.)

Kevin: Stacks are simple to teach and simple to implement. Stack operations, however, are inherently linear. For quite a few years now, all mainstream processors have been superscalar (supporting parallel instruction execution). One of the key roles that caches and register files play in modern processors is to widen the window of instructions which can be analyzed and scheduled for parallel execution. Register based VM architectures remove the overhead of administrative stack operations and map efficiently to the data caches of modern processors.

NOTE: Dan's answer here is better than mine. The above is my opinion, I'm not well versed in this area. I know that stack lovers will say that stacks can map efficiently to register file based processors as well. It was a decision, it's made, life goes on. This issue really gets blown out of proportion. Its not that big of an issue.