Linked by Shlomi Fish on Sat 16th Oct 2004 07:28 UTC
General Development The purpose of this essay is to explain why I believe Perl 6, the way it currently seems to progress, is the wrong thing at the wrong time, and why I predict (with all the expected caveats of predicting something) that it won't be successful. I will also suggest a better alternative for the future of Perl which makes more sense at this point.
Permalink for comment
To read all comments associated with this story, please click here.
Parrot
by Treza on Mon 18th Oct 2004 10:49 UTC


I don't understand what is so great about Parrot. ( btw, I'm not a seasoned Perl programmer. )

I've recently overlooked the code to get some "inspiration" for the VM of a language I'm currently creating ( or maybe switching the VM to Parrot )

I've seen :
- Parrot was initally a register based VM with 32 integer registers, 32 float, and many others.
- They have implemented some JIT system to transform the VM code into native code on many targets.
- They have built an assembler, which is now deprecated.
- They have created several [ mostly toy ] language frontends.
- One of the toy language has been transformed into a "intermediate level" language that shall be generated by the real language frontend instead of generating directly Parrot assembly. That IL compiler does registers allocation.
- Many signifiant changes have been made to the VM, like switching to continuation style calls ( I'm not sure ).

IMHO :
- The Parrot VM is squeezed between the IL code and the JIT compiler. For example, no real hardware has 32 integer registers available simultaneously for user code ( and most common HW has only 8 integer registers, you seen what I mean ? ). The IL compiler maps locals to 32 registers whereas the JIT needs to reduce the effective number of registers to map into hardware.
- They have chosen a register based architecture that is supposed to be more efficient than stack computers. I'm not sure it's always true for VMs. I think that register allocation would be simpler for the JIT compiler with an arbitrary length stack VM.
- For me, a VM shall be kept virtual. If your VM looks too much like an ordinary microprocessor, you miss most of the outstanding benefits of a VM ( for example, my language' VM has only 20 opcodes, and half of them have no direct HW equivalent ). With so many statically typed VM registers you can't play easily with advanced concepts like continuations, coroutines...
- Basically, when you design a VM, the way the Machine works is an unimportant detail. For example, memory allocation is more complex. The virtual machine is an interpreter and not a processor, and, in that aspect, I think that the Java VM is not abstract enough. A "higher level" VM may be slower in interpretative mode but you can make it more versatile and, in the end, as you will need a JIT compiler, you need something more abstract than a simple processor for better optimisations, you can even add to the code some optimisation hinting like : {that parameter won't be used afterwards} {that local doesn't need initialisation} {you can inline that function} {doesn't call subs} {it's tail recursive} ...

For resource limited targets the VM shall be very simple. For more powerful computers, you have plenty of time and memory to do JIT compilation.

Parrot seems to be a bad solution to a nonexistant problem.

Now, who can tell me where am I wrong ?
( No flames, please )



BTW, Perl 7 exists already, it's called Ruby ! <grin>