Parrot Updates

BorrisYeltsin writes: "A couple of updates for Parrot are in a recent This Week on Perl 6, most imporantly Parrot 0.03 is out! Get it here , the release notes are here. Also Adam Turoff has got together the Parrot FAQ version 0.2 which addresses some of the more common questions about Parrot and Perl 6."

Comments

Old News

[mshiltonj]

Parrot 0.0.3 was released way back on the 11th of dec, nearly three weeks ago.

If you want *new* news on perl/parrot, the latest parrot in CVS is now "fully-functional" (interpret that however you want.)

Spam

[Matts]

A large number of perl web sites have been spammed with this. I consider the manner in which it's been done quite rude, as it has in no way been personalised, and is very "spam" like in appearance (i.e. it's saying that DeveloperWork's articles are of the highest quality - well they would, wouldn't they?).

I'm not disputing the quality of the articles there, just pointing out that this has gone to several places, and even been posted on a few sites. I didn't post it on the one I admin because it was totally impersonal.

Re:FAQ leaves me concerned.

[Elian]

Since this seems to be serious, please consider the advantages of a mixed register+stack machine. With 3 32 bit stacks and one 64 bit stack (though if you are using FORTH, you can use the FORTH model, and drop the last one at the expense of having a set of double-cell primitives.

This has been part of the design from the very beginning. In addition to a general purpose stack, each of the register types has a stack associated with it so you can push and pop all the registers of a particular type at once.

The reason for hardware registers is that in hardware fast memory is an expensive and scarse resource.

That's not the only reason. Bits and memory bus bandwidth are also scarce resources, and a small set of named scratchpad spots allows for significant speedups over fully qualifying everything with a memory location.

But in a software implementation, the registers run in the same memory space as the rest of the program. So they loose many of their advantages.

Many, but not all. The stack thrash is a big issue as well and, while there are ways to get around it by allowing references back in the stack, they're generally more awkward than a plain register setup.

There's also an awful lot of literature on writing optimizers which is geared towards register machines, as that's what everyone's CPU is these days. I've not found much readable literature on optimizing a pure stack-based system.

They can, however, save a level of indirection. And that can speed things up if it's on something that is being done frequently. So one alternative is to define the largest stack frame that one wishes to allow for, provide a way for a stack frame to be copied to a fixed location, and then have analogous operations based either on the fixed location, or on a stack frame pointer in the stack. So the stack is a set of modifiable stack frames (though only the top stack frame at any time is resizeable).

Congrats, you just described a register-frame system. Which is what we already have. :)

However, if one isn't modeling an existing hardware implementation, then the virtual machine should not end up looking like any of the hardware.

One is always modelling hardware. That's what this stuff ultimately runs on. You can't ignore the underlying system if you want really good performance. And while a good chunk of our userbase is running on register-starved systems (x86) a lot aren't. The design's not got any serious disadvantages relative to a stack system on x86, and some good advantages on machines with plentiful registers (alpha, sparc, PPC, MIPS, IA64) so it's a win.

Re:OT: question about hyper operators.

[LunaticLeo]

Perl6 is not going to be as explict about this as K apparently is. In perl6 we already know the context of variable because of all the $@% stuff. So we don't need to specify left/right variations of the same operator.

Your examples become:

@x = (1, 2, 3);
@y = (10, 20, 30);
$z = 100;

@x ^+ @y is (11, 22, 33)
@x ^+ $z or $z ^+ @x is (101,102,103)
$z ^+ @y or @y ^+ $z is (110,120,130)

# There is probably a more clever Perl6 way
# also correctness is not guranteed
map { ($_ ^+ @y) } @x is (11 21 31; 12 22 32; 13; 23 33)
map { ($_ ^+ @x) } @y is (11 12 13; 21 22 23; 31 32 33)

There is no @a ^^+ @b for the last two examples, but you might be able to defined your own operators and have the hyperoperator work on it.

But Perl6 does not seem to want to go as far as your language K does. However, modifying the syntaxt of Perl6 on the fly is going to be VERY easy. Something like:

use Ksyntax;

@a ^\+ @b; #like x +\: y
@a ^/+ @b; #like x +/: y

no Ksyntax;
#back to normal

-LL.