The Perl 6 summary for the week ending 20030223
Another week, another Perl 6 Summary, in which you'll find gratuitous
mentions of Leon Brocard, awed descriptions of what Leopold Tötsch got
up to and maybe even a summary of what's been happening in Perl 6 design
and development.
Kicking off with perl6-internals as usual.
Strings and header reuse
Dan responded to prompting from Leo Tötsch about the use and reuse of
string headers. The problem is that most of the string functions that
produce modified strings do it in new string headers; there's no way of
reusing existing string headers. This can end up generating loads of
garbage. Dan's going through the various string handling ops and PMC
interfaces working out what needs to do what, and documenting them, as
well as adding in versions of the ops that take their destination string
headers as an argument. Dan hopes that 'we can make the changes quickly
and get this out of the way once and for all', leading Robert Spier to
mutter something about 'famous last words'.
<http://makeashorterlink.com/?Z13621793>
PXS help
Tupshin Harper has been trying to use an XML parser from within Parrot
and started off by looking at the PXS example (in examples/pxs) but had
problems following the instructions given there as his compiler spat out
errors by the bucket load. Leo Tötsch thought that PXS was probably
deprecated and the native call interface (NCI) was the thing to use.
Being Leo, he provided a port of the PXS Qt example to NCI. Although PXS
appears to be out of sync with the parrot core, nobody was entirely sure
whether it should be removed.
<http://makeashorterlink.com/?V14632793>
Bit rot in parrot/language/*
Tupshin Harper had some problems with some of the language examples not
working well with the most recent versions of Parrot. Leo Tötsch
addressed most of the issues he raised, but there are definitely issues
with the interpreter and the languages getting out of sync.
<http://makeashorterlink.com/?O55624793>
<http://makeashorterlink.com/?S26652793>
Macros in IMCC (part 2)
Jürgen Bömmels extended the macro support in IMCC, implementing
".constant" and adding some docs. The patch was promptly applied.
<http://makeashorterlink.com/?G17656793>
[RFD] IMCC calling conventions
Leo Tötsch posted an RFD covering his understanding of the various
calling conventions that IMCC would have to deal with which sparked some
discussion. I'm now confused as to whether function calls in Parrot will
be caller saves, callee saves, or some unholy mixture of the two.
<http://makeashorterlink.com/?F68641793>
Parrot performance vs the good, the bad and the ugly
Tupshin Harper decided to port primes.pasm to C and Perl 5 to compare
results. Parrot came out very quick indeed. (Close to C). For bonus
points he then took a python primes algorithm that had been ported to C
and ported that to Parrot as well. In full on, all stops pulled out,
knobs turned to 11 mode, Parrot came in at about 50% slower than C and
around 14 times faster than Python. There was some muttering about the
demo being rigged. However, Jim Meyer redid the Perl and Python
implementations to use a loop that duplicated the algorithm used in
primes.pasm and, whilst it improved their performance somewhat, Parrot
was still substantially faster.
This probably won't be the test that's run when Dan and Guido face the
possibility of custard pies at 10 paces or whatever the performance
challenge stake stands at now.
<http://makeashorterlink.com/?I29621793>
Mmm... spaceships...
Leon Brocard patched examples/assembly/life.pasm to use a small
spaceship as its starting pattern. Apparently because it 'can provide
hours of enjoyment at conferences if projected onto a big screen while
answering parrot questions.' Nobody thought to ask him how a spaceship
was going to answer Parrot questions, but Leo Tötsch applied the patch.
<http://makeashorterlink.com/?X2A613793>
Using IMCC as JIT optimizer
Apparently, Leo Tötsch finds it unbearable that 'optimized compiled C is
still faster than parrot -j' so he's been experimenting with adding
smarts to IMCC, making it add hardware register allocation hints to its
emitted bytecode. Sean O'Rourke liked the basic idea, but reckoned that
the information generated by IMCC should really be platform-independent,
suggesting that it'd be okay to pass a control flow graph to the JIT,
but that hardware register allocation for a specific number of registers
would iffy. He suggested that another option would be for IMCC to 'just
rank the Parrot registers in order of decreasing spill cost', then the
JIT could just move the most important parrot registers into
architectural registers.
Dan thought the idea was interesting too, but worried that the JIT might
spend more time optimizing code than it could possibly gain from the
optimization. The discussion got more than a little technical after
this. I'm afraid I'm a bear of little brain when it comes to this sort
of magic, so you'll have to read the whole thread if you're interested
in the details.
The response was pretty positive throughout the discussion, so Leo went
ahead and implemented it. The new, improved version shaved slightly more
than a tenth of a second from the primes.pasm runtime (not a great
percentage win, but the total runtime includes the compilation time)
<http://makeashorterlink.com/?U2B622793>
<http://makeashorterlink.com/?P2C651793>
"invoke"
Steve Fink is bothered by the "invoke" op because it operates implicitly
on P0. He wants to replace it with a new version that takes a PMC
argument. Leo Tötsch is less bothered by the implicit behaviour of the
op, but would like to see an additional "invoke_p" op, which would take
a single PMC argument. So Steve implemented it, but hit a couple of
snags. I'm not quite sure whether these have been overcome yet.
<http://makeashorterlink.com/?U1D642793>
Problems with "Configure.pl --cgoto=0"
Nicholas Clark was unable to build Parrot with computed gotos turned
off. Simon Glover offered a simple patch that fixed Nick's problem. Leo
Tötsch talked about the different reasons for not building a computed
goto core, which depends on both the compiler's capabilities and the
user's choices. This led to a discussion of which cores were now
obsolete. Leo believes that the simple Computed Goto and Prederef cores
have been obsoleted by the CGP core (Computed Goto Prederefed). Nick
thought we should continue to ship code for all the cores, and ensure
that the config system is flexible enough to let anyone build any
arbitrary combination of cores, which convinced Leo. Dan suggested that,
once we'd done this we should revamp the Tinderbox system to run tests
on all the core types.
<http://makeashorterlink.com/?R1E621793>
Non-inline text in parrot assembly
Tupshin Harper wondered if there were any plans for Parrot to support a
distinct ".string" asm section. Leo Tötsch pointed to ".constant" (in
PASM) and ".const" (in IMCC) as ways of keeping strings visually
together. Tupshin realised he'd missed a chunk of documentation
("perldoc assemble.pl" for anyone else who hasn't read it) which he
thinks should probably be moved into docs/parrot_assembly.pod or
somewhere similar.
<http://makeashorterlink.com/?P2F621793>
Access to partial registers?
Tupshin Harper wondered if it was possible and/or meaningful to read and
write from a part of a register (eg. a single word) in PASM. Answer: Not
at the moment, what do you want? We can always add an intreg.ops set.
<http://makeashorterlink.com/?W20742793>
Meanwhile, over in perl6-language
Things were, once more quiet (all of 16 messages). I think we're all
awaiting the coming of the Prophet Zarquon (or possibly the next
Apocalypse, whichever comes soonest.)
Arrays, lists, referencing
David Storrs suggested some possible semantics for "(4, 1, 2) + 7",
noting that he doesn't like the Perl5's current behaviour (evaluates to
9). Michael Lazzaro thinks it should evaluate to 10 (length of the list
+ 7) or possibly throw a syntax error. This then morphed into a
discussion of pass by value, pass by reference and pass by constant
reference, which Allison Randal told us would be addressed in the
upcoming Apocalypse 6.
<http://makeashorterlink.com/?Y41731793>
Err...
That's it
Acknowledgements, Announcements and Apologies
Mmm... the comfy chair... it's the only place to write a summary in.
Especially when you're plied with lashings of Earl Grey tea and
entertained by the antics of a couple of adolescent cats. Things could
be lots worse.
I'd like to apologize to Danny O'Brien for last weeks mention of 'a
Brainf*ck compiler, in Brainf*ck, for the Brainf*ck interpreter supplied
with Parrot, a virtual machine named after a joke, written for a
language that doesn't yet exist.' Apparently this sprained Danny's head.
And I extend similar apologies to anyone else whose head was sprained by
that concept.
The American Odyssey web page is still more of a beautiful idea than an
actual link you can click. Hopefully it'll spring into existence before
we set off, but I wouldn't bet on it.
Aspell is, once more, the weapon of proofreading choice.
If you appreciated this summary, please consider one or more of the
following options:
* Send money to the Perl Foundation at
<http://donate.perl-foundation.org/> and help support the ongoing
development of Perl.
* Get involved in the Perl 6 process. The mailing lists are open to
all. <http://dev.perl.org/perl6/> and <http://www.parrotcode.org/>
are good starting points with links to the appropriate mailing
lists.
* Send feedback, flames, money, job offers or his and hers Mini
Coopers to [EMAIL PROTECTED]
This week's summary was again sponsored by Darren Duncan. Thanks Darren.
If you'd like to become a summary sponsor, drop me a line at
[EMAIL PROTECTED]
--
Piers
