This week on Perl 6, week ending 2003-04-27
by Piers CawleyApril 27, 2003
Welcome back to (I hope) a normal length summary of Perl 6 shenanigans after last week's bumper double length installment. (Thankfully traffic has been much lighter this week; I'm not sure I could cope with writing another epic.)
Perl6-internals was quiet again this week, but traffic does appear to be picking up a little.
IMC and Variable Number of Arguments
Following on from questions on this subject last week, Klaas-Jan Stol asked for some clarification of Parrot calling conventions as documented in Parrot Design Document (PDD) 03. In a subsequent post he noted that it seems strange that the current perl6 implementation (such as it is) doesn't follow the Parrot calling conventions. Sean O'Rourke shuffled his feet slightly and admitted that he'd chosen that method because ``It was easiest'', though he'd later rationalized that to ``It doesn't matter for internal calls''. Dan Sugalski pointed out that it was only a temporary aberration. Unless I missed something, nobody actually answered Klaas-Jan's initial questions.
http://groups.google.com/groups
Short-lived memory allocation
Last week, in a discussion of the Garbage Collection (GC) system, Dan mentioned that Parrot GC would walk the system stack in order to build the Root Set (the list of memory 'nodes' that are initially known to be alive) which makes life a good deal easier for anyone allocating memory because they don't have to worry about explicitly attaching their shiny new buffer to the root set. Of course, it doesn't lessen the pain of whoever writes the GC system because, as Benjamin Goldberg pointed out, any system stack walking system is inherently unportable.
Benjamin was concerned that there may be systems where, not only could you not use the same stack walking code as was used everywhere else, but it would be impossible to walk the system stack at all. Dan admitted that there 'used to be' such systems, but asserted that, for Parrot's purposes ``Either we get access to the C auto variable chain, or we can't run there.'' Kurt Stephens pointed at some deeply scary sounding (and gloriously non-portable) system stack walking methods which involve co opting the C stack pointer and collecting garbage from unlikely places...
If you're not sure what is meant by 'Walking the system stack' then you're not alone. Tim Howell asked for clarification and received it from Matt Fowles and Brent Dax.
http://groups.google.com/groups
http://groups.google.com/groups
PMC Documentation
Alberto Simões continued on his mission to document Parrot's various PMC classes. This week he offered up some Perlstring documentation
http://groups.google.com/groups
The Native Call Interface (NCI) system.
Michael Collins has been playing around with calling C from Parrot and
found the NCI system rather cumbersome. He wondered if the whole thing
couldn't simply be implemented with a callcfunc opcode and showed a
simple implementation of what he was driving at. Dan replied to this,
explaining that he'd considered it but that it turns out not to be the
Right Thing, and gave his reasons to do with encapsulation (when you
call a PMC's method you shouldn't have to know whether it's written in
C, PASM or Befunge) and issues with dynamic generation of stub
functions. Michael wasn't entirely convinced by Dan's argument.
On the subject of NCI, Clinton A Pierce wondered if it is supposed to be Win32 capable and, if it was, what he needed to do to get it working as his first attempt had failed. Currently on the horns of Warnock's Dilemma.
http://groups.google.com/groups
http://groups.google.com/groups
use for p6c
Joseph F. Ryan resent his patch to implement use in Parrot's Perl 6
implementation, this time as a straight CVS diff on Steve Fink's
request.
http://groups.google.com/groups
Building on Win32
Matthia Barbon continued his sterling work on getting Parrot to play well with Win32, offering a couple of patches. Steve Fink applied them both.
http://groups.google.com/groups
http://groups.google.com/groups
External Data Interfaces draft PDD
Matthia Barbon redrafted Brent Dax's External Data Interfaces PDD based on the discussion of the original document. This elicited a few comments and I presume we can expect another, clarified draft at some point.
http://groups.google.com/groups
PPC JIT questions
Peter Montagner has started to work on the Just In Time (JIT) system for the PowerPC architecture (a chap can get tired of making sure that every initialism is expanded at least once in a document you know. Still, it's been a few summaries since I last did anything like this) and had a couple of questions about its architecture and what he was allowed to do in PPC assembly. Dan answered, Peter asked for clarification; the usual give and take.
http://groups.google.com/groups
A question about encoding
Speed junkie Luke Palmer (Hmm... that may not mean quite what I want
it to mean) is working on the next iteration of string_str_search,
which, apparently isn't fast enough (it's still slower than Perl
5). He had a few questions about encodings. Benjamin Goldberg offered
answers and an entire function. Luke was impressed, but he still
muttered about how much faster single byte searching could be (he's
written a singlebyte/singlebyte search routine that goes slightly more
than 2.5 times faster than Perl 5 apparently).
Later, Luke posted a new implementation of string_str_search which
used his screamingly fast algorithm for single byte searching and a
'stupid, slow algorithm' for multibyte searches. Steve Fink applied
the patch and asked for a unified diff next time as they are easier to
read.
http://groups.google.com/groups
http://groups.google.com/groups
Leo Tötsch's iterator proposal
Remember Leo Tötsch's iterator proposal that received so little feedback a few weeks back? Steve Fink finally commented.
http://groups.google.com/groups
uniq.pasm and Parrot IO
About a month ago, Jürgen Bömmels was doing some work on the moving Parrot's IO operators to use Parrot's own PIO asynchronous IO system, which broke Leon Brocard's uniq.pasm. Jürgen estimated that he might have it working 'next weekend'. This week Leon asked if any progress had been made yet.
http://groups.google.com/groups
Pages: 1, 2 |
