This Week in Perl 6 (20 May - 26 May 2001)



Notes

You can subscribe to an email version of this summary by sending an empty message to perl6-digest-subscribe@netthink.co.uk.

Please send corrections and additions to perl6-thisweek-YYYYMM@simon-cozens.org, where YYYYMM is the current year and month.

Perl "Assembly Language Standard"

A.C. Yardley submitted a proposal for documenting PDDs with the very-low-level operations of the Perl Virtual Machine itself. (This is a separate idea from the assembly language that will also be written.) A.C. will continue to work on it.

The "Perl Apprenticeship Program" Revisted

A.C. Yardley also revisited an old thread about a Perl Apprenticeship Program.

Nat Torkington:

Not to speak for Dan, but there's no code yet to review or learn from. I'd love to see someone set up a perl *5* apprentice program, and Mark-Jason Dominus has some ideas on how it might work. For perl6, though, we're not yet at a place where I think it makes sense. Right now there's so little defined in the way of implementation, that questions can be asked and answered on the mailing list.

Simon, however, felt that the group was almost at the point where some coding could start, and suggested that folks whisk through the sv.c, av.c, and hv.c Perl 5 code (describing scalar, array, and hash functionalities, respectively) to summarize what actually needs to be implemented.

Dave Mitchell and A.C. Yardley accepted the challenge.

Perl Virtual Registers

Dan Sugalski pushed for a register-based Virtual Machine, vice a stack-based machine, with little real dissention on that point. Dan, however, wanted typed and linked registers, but opinions were mixed on having typed registers, and generally opposed to having them linked.

Uri Guttman and Nick Ing-Simmons then took over the thread to banter about dealing with the stack/register window that will be necessary with threads and register overflows.

Here's a snippet from Uri's last response:

NI> That makes sense if (and only if) virtual machine registers are real 
NI> machine registers. If virtual machine registers are in memory then 
NI> accessing them "on the stack" is just as efficient (perhaps more so)
NI> than at some other "special" location. And it avoids need for 
NI> memory-to-memory moves to push/pop them when we do "spill".

no, the idea is the VM compiler keeps track of IL register use for the purpose of code generating N-tuple op codes and their register arguments. this is a pure IL design thing and has nothing to do with machine registers. at this level, register windows don't win IMO.

And a snippet from Nick's:

... My point is that UNLESS machine (real) machine registers are involved then all IL "Registers" are in memory. Given that they are in memory they should be grouped with and addressed-via-same-base-as other "memory" that a sub is accessing. (The sub will be accessing the stack (or its PAD if you like), and the op-stream for sure, and possibly a few hot globals.)

The IL is going to be CISC-ish - so treat it like an x86 where you operate on things where-they-are (e.g. "on the stack")

   add 4,BP[4]

rather than RISC where you

   ld BP[4],X
   add 4,X
   ST X,BP[4]

If "registers" are really memory the extra "moves" of a RISC scheme are expensive.

Slices

Raul Miller threw out some ideas about slice syntax. There was some minor discussion centered around whether an array index in the new syntax is in scalar or list context by default.

This led to David Whipp proposing a new index context, to parallel the other contexts that Perl is aware of.

Slice References

Peter Scott bridged a posting from the perl beginners list, asking if it would be possible to allow non-copying slice references in Perl 6.

Damian Conway, of course, said, of course, "Of course":

@A = (1..10);   # array
sub sliceref
 {my($i,$o,$k)=(0,0,pop);$i+$o-$k->[$i]?++$o&&splice@_,$i,1:$i++while$i<@_;\@_}
my $ref = sliceref @A, [3..5,9];        # reference to slice
print "@A\n";
print "@$ref\n";
$ref->[1] = 99;
print "@A\n";
print "@$ref\n";

Properties Continued

The head-wrapping continued on the new properties feature of Perl 6. Although Damian gave some encouraging answers, he eventually posted:

I have already been discussing this with Larry and have privately sent him a complete proposal that, I believe, addresses all these issues. Let's wait and see what he makes of that proposal.

The Parrot Squawks

There has long been confusion between Perl (the community), Perl (the language), and perl (the program). This is only exacerbated on the inside with various bits and pieces of Perl's (and perl's) guts. Add the complexity that Perl 6 is promising to add, and you've got a maze of twisty little passages, all named "Perl."

Now, a while back, Larry countered a suggestion to use Parrot as the project name for Perl 6 with a list of codenames for various pieces, but it seems that Dan has been slipping it in anyway. (The name Parrot, of course, is from Simon's tomfoolery earlier this year.) So it seems that at least the Perl 6 internals has a new moniker.

Until next week...


Bryan C. Warnock
Visit the home of the Perl programming language: Perl.org

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en