This week on Perl 6, week ending 2003-02-23

Feb 23, 2003 by Piers Cawley

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

http://groups.google.com/groups

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://rt.perl.org/rt2/Ticket/Display.html

[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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

http://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

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:

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 p6summarizer@bofh.org.uk.

Tags

perl-6
perl-6-internals-parrot

Feedback

Something wrong with this article? Help us out by opening an issue or pull request on GitHub