This week on Perl 6 (week ending 2002-08-04)

by Piers Cawley
August 05, 2002

Back on the regular schedule complete with new and improved article links via those lovely people at Google groups. Hopefully, we'll be staying on this schedule for the foreseeable future.

As usual, we'll kick off with perl6-internals, which was, once again, the busiest group this week.

We Need More Ops

This thread rumbled on (slowly) with a mixture of serious and humorous messages. Melvin Smith worried that parrot would turn into "a Linux kernel and forever accumulates custom ops, PMCs."

The appropriately named Eric Kidder proposed ':-) the Positivity operator. Nobody threw peanuts.

http://groups.google.com/groups

http://groups.google.com/groups

Of Mops, JIT and perl6

This thread kicked off the week before, but carried on into this week. Leopold Toetsch had got some MOPS numbers for various bits of parrot, including the perl6 mini language. Dan wondered whether the perl6 numbers included the time to generate the assembly and assemble it, because the assembler is 'rather slow.' Sean reckoned that, compared to the parser, the assembler was quick and that he suspects that even without that the perl6 numbers "would suck, since the compiler does some pretty heavy pessimization." Melvin Smith reckoned that imcc may have had something to do with the slowness as well, because it didn't do the right thing with loop invariants, but that "things can only get better."

Leopold then told us that the numbers were pure runtime and that the compilation phase added 2.3 seconds to the whole process. Ick. However, following a bugfix to perlarray.pmc he posted new numbers that were "not that abysmal," and that we already have the same MOPS as perl5 ... .

http://groups.google.com/groups

http://groups.google.com/groups

http://groups.google.com/groups

Dan Sugalski Is Back

And it's like he never went away. At the top of his list is catching up with his mail, sorting out keys, defining the extension mechanism, the exception infrastructure, ruthless efficiency and a fanatical devotion to the Pope.

He also suggested that if someone were to implement the cmpi and cmps ops for integer and string comparison, then that would be a good thing. Sean O'Rourke asked questions about that, and the semantics of 2 < $i++ < 23 were discussed

http://groups.google.com/groups -- Start here.

Regex Speedup

Angel Faus has been working on the regex engine and provided a patch for it, "designed with the single goal of seriously cheating for speed." Dan applauded and claimed to be feeling "decidedly superfluous", but wondered whether Angel could use the -u or -c switches to diff next time.

Also on the regex front, Stephen Rawls offered some better documentation of the regex subsystem.

http://rt.perl.org/rt2/Ticket/Display.html

http://rt.perl.org/rt2/Ticket/Display.html

ARM JIT v2

Nicholas Clark released a "very minimal" ARM JIT framework. The initial version only JITed a small number of trivial ops, but it's the framework that was important. Daniel Grunblatt sent Nicholas a copy of the work he'd done in that area and we ended up with a new, unified patch that handled a whole lot more ops, and which wondered where the PPC JIT had got to. It turns out that Daniel is working on that, too. Go Daniel.

On the subject of JITs, Jarkko Hietaniemi, fresh from his trials as the perl 5.8 pumpking popped up with a survey of the state of the JIT art in parrot. Apparently we're still missing PPC and POWER, MIPS, HPPA and IA64. Jarkko intends to "do nothing on these except raise gui^H^H^Hawareness :-)". Which is nice of him.

Nicholas also wondered whether he was "allowed to write ancillary functions I want the JIT to call in assembler?" Dan reckoned that, in a JIT, "evil things for speed reasons are almost obligatory."

http://groups.google.com/groups

http://groups.google.com/groups

http://groups.google.com/groups

http://groups.google.com/groups

Lexical Scope Ops, Test and Example

Jonathan Sillito offered a patch that implements lexical pads and some ops to manipulate them. Stephen Rawls pointed out a bug in the implementation, and Dan agreed that it was a bug but that once that was fixed the patch should go in, because "it gets a good chunk of the semantics we need." (Speaking as someone who keeps making noises about implementing Scheme in parrot, having parrot native lexicals will be a *huge* win.) So, Jonathan fixed it, and Melvin applied it.

This led Jerome Vouillon to wonder whether we actually needed explicit lexicals and scratchpads. The thread is rather tricky to summarize, so I'll just point you at it. However, Dan chimed in to say that, for now at least, he'd rather keep the separate interface to lexicals and globals because it would make changing the implementation possible without breaking existing bytecode.

http://rt.perl.org/rt2/Ticket/Display.html

http://rt.perl.org/rt2/Ticket/Display.html

http://groups.google.com/groups

Unifying PMCs and Buffers for GC.

Dan has accepted that we need to unify PMCs and strings/buffers for GC purposes, and asked for volunteers. Mike Lambert stepped forward (or maybe everyone else took one pace back). Again, this thread is hard to summarize because it's so information dense. If you're interested, then you should read the whole thread.

http://groups.google.com/groups

Pages: 1, 2

Next Page