Parrot 1.0.0 Released
outZider writes "Parrot 1.0.0 was released last night! The release of Parrot 1.0 provides the first "stable" release to developers, with a supportable, stable API for language developers to build from. For those who don't know, Parrot is a virtual machine for dynamic languages like Perl, PHP, Python, and Ruby, and is best known as the virtual machine for Rakudo, the reference implementation of Perl 6."
One Bytecode to rule them all, One Bytecode to describe them, One Bytecode to bring them all and in the OS bind them.
I'll tell you what's wrong with it, my lad. 'E's slashdotted, that's what's wrong with it!
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
This is the first time I heard about Parrot, and it really got my attention as well.
I know it's common knowlegde, but you can get more information in wikipedia:
http://en.wikipedia.org/wiki/Parrot_virtual_machine
Enjoy!
If I clone myself, can I call it a thread?
If a girl winks to us, can I call it a race condition?
try this:
http://lwn.net/Articles/324196/
Climate Progress - Hell and High Water
Probably; that usually happens when someone posts a link to the internet on Slashdot. Someone really needs to update the server for the internet.
Remember that their plans for the 1.0 release was for a stable API for language implementors, not highly optimized performance.
Surprisingly. The idea is to do a full language specification, so there can be many implementations of a language, similar to how Java (theoretically) works. This is also why there is an absolutely huge, yet incomplete, test suite. More tests are passing weekly, but more tests are being generated weekly.
- oZ
// i am here.
Question from somebody who's done some compiler work with VMs but not Parrot...
What does Parrot do that other VMs can't (e.g. the .NET dynamic language runtime on the CLR, or the JVM?)
Without knowing better, it seems like a lot of duplicated effort to me...
Tolkein didn't write a line of Perl 5 either, yet Larry quotes him in his release announcements. Epigraphs are long-established literary traditions.
how to invest, a novice's guide
Parrot 1.0.0 was released last night! The release of Parrot 1.0 provides the first "stable" release to developers, with a supportable, stable API for language developers to build from. For those who don't know, Parrot is a virtual machine for dynamic languages like Perl, PHP, Python, and Ruby, and is best known as the virtual machine for Rakudo, the reference implementation of Perl 6.
SQUAWK! On topic!
Version 1 is supposed to be reasonably complete and provide a consistent API for language developers.
Version 2 is intended to be the production-ready version. According to the roadmap laid out last Dec., that's due to come in another year. So far, they've stuck to the roadmap pretty well.
Not a typewriter
Slightly off topic: Is there a compiler for Perl, that is not based on bytecode, and therefore is difficult to decompile?
I thought perl source was considered sufficiently obfuscated that it was safe from reverse-engineering in source form. Why on Earth would you want to do something like this anyway?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
When we all know the real announcement ought to have been "Brawk! Ready to sail"
I am officially gone from
Perl 5 isn't really bytecode at all. It basically just walks the parse tree directly.
Perl 6/Parrot is bytecode just as those from Python or Java have come to expect. Perl 5 could be reimplemented this way, but nobody seems to want to bother.
If your goal is to obfuscate your code to prevent people from copying it, please give up.
Not a typewriter
It included a mock press release: Perl and Python Announce Joint Development.
And a joint "interview" of Larry and Guido.
O'Reilly Media even tossed in a bogus book announcement: Programming Parrot in a Nutshell.
A few days later, O'Reilly published The Story Behind the Parrot Prank.
The name was eventually adopted by this project.
Considering the JVM is a stack machine VM for statically typed languages, .NET is a stack machine VM for statically-typed languages, and Parrot is a register machine VM built for dynamically-typed languages perhaps it's not so "me too".
The differences aren't nearly as profound as you might think. Keep in mind that when the software is translated from bytecode to native code via JIT is when the real magic happens.
Since the Java and .NET implementations are further abstracted from the underlying hardware implementation, their VMs have a lot of opportunity to optimize between the registers and the stack. They can even undo certain optimizations and realign their mappings between stack and registers. (The ability to reoptimize is why the JVM is referred to as "Hotspot". It looks carefully for "hot spots" in the code where much of the execution time is being spent, then optimizes the code according to how it has been used at runtime.)
The Parrot VM's use of registers makes it easier to map those registers to the underlying hardware, but it makes it more difficult for the JIT to decide what belongs in a register and what should be moved to stack. The bytecode may force the use of registers that end up not being ideal at runtime. Similarly, the VM may miss the opportunity to move critical stack information to registers, thereby slowing down the execution of the code. The obvious solution is to abstract away from the registers and treat them as part of the stack. From there, the JIT can treat these values holistically. And thus we end up with a solution that looks a lot like a stack-based VM.
Mod grandparent up. Mod parent down.
There is Perl 6 release each month.
The Case for Virtual Register Machines, Brian Davis, Andrew Beatty, Kevin Casey, David Gregg and John Waldron, 12.6.2003, PDF
http://search.cpan.org/~nwclark/perl-5.8.9/ext/B/B/Bytecode.pm:
NOTICE
There are also undocumented bugs and options.
THIS CODE IS HIGHLY EXPERIMENTAL. USE AT YOUR OWN RISK.
AUTHORS
Originally written by Malcolm Beattie and modified by Benjamin Stuhl .
Rewritten by Enache Adrian , 2003 a.d.
B::Bytecode is an experimental feature that's been largly abandoned since 2003. Perl5 is too much of a mess to make a bytecode compiler work. That's why Parrot exists.
Not a typewriter
Rather...
But, yeah, I'm with you. The basic idea is that you can't read Perl if you're not literate. At least to the degree of the author of the work you're reading. So, basically, anyone who says Perl is hard to read is a bystander.
Perl can be hard to read if you don't know it. But it can be wonderfully concise if you do. That concision is valuable, so I'll take that. Even if it means having to learn the language first.
That's because register-based interpreters are faster than stack-based interpreters. Generally speaking, the fewer instructions you run in a bytecode interpreter, the faster it will execute. That is the argument made in the paper posted by mj41 above.
When you throw a JIT into the mix, things change rapidly. You stop being concerned about the interpreter speed and begin worrying more about machine code optimizations. What's good for the goose may be good for the gander, but what's good for the interpreter is not always good for the JIT.
Interestingly, there is only one Javascript JIT in wide distribution at the moment. That is Chrome's V8. Tamarin is also used in Flash 9 & 10 and is expected in future versions of Firefox.
Unfortunately, JITs are much more resource intensive to develop and maintain than interpreters. Thus a small company like Opera isn't going to make a JIT their first priority. A fast interpreter makes a lot more sense from their perspective. Especially when the Javascript engine spends the vast majority of its time in native APIs.
Javascript + Nintendo DSi = DSiCade
If you don't know the language, what are you doing maintaining Perl code? I consider that professionally irresponsible, at least if you're getting paid.
Oh, absolutely, no question there. I was thinking of people messing around for fun, not getting paid to maintain Perl code in a professional environment.
(Where do you look up the /g flag for the JavaScript example?)
When you look up the String.replace method, it should explain /g there. In my Perl example, you have to recognize that ~ is actually part of the =~ operator, and that s is part of the s/// operator; once you know what these are, you can look them up in perlop (and indeed, /g is explained there).
Obviously this isn't a realistic example; any Perl beginner should know the syntax I used. My point was that because other languages rely more heavily on functions to accomplish things that Perl has a unique syntax for (which makes Perl easier and more fun to write), other languages are easier to read because when you come to a function you're not familiar with you can easily look it up. With Perl, if you don't recognize the syntax, you don't know what to look up, so you're stuck (or you misinterpret what's going on).
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;