The Perl 6 Summary for the week ending 20030302
Welcome back to another episode in the ongoing saga that is the Perl 6
development process (or at least my attempt to describe it).
We kick off with perl6-internals.
IMCC calling conventions
Piers Cawley attempted to describe tail call optimizations, why they
were a good thing and why a caller saves calling convention made such
optimizations easier (possible?). He wondered if he hadn't just
succeeded in muddying the waters still further. Jerome Vouillon appeared
to understand what Piers was going on about and pointed out that a
caller saves scheme also helps with exception handling. Benjamin
Goldberg wondered about Perl 5's "goto &func" semantics which can be
looked at as a 'sort of' tail call (except you don't actually get much
of an optimization with Perl 5 as it stands) and proposed a callee saves
scheme for doing tail call optimization which didn't optimize away an
unnecessary pair of save/restores. Dan pointed out that, while "goto
&func" (which is sort of like tail call optimization in Perl 5) would
have to be supported, tail call optimization made more sense if you
didn't have to use any special syntax to make use of it.
<http://makeashorterlink.com/?J18326AA3>
A couple of easy questions...
David (Cuny?) wondered how he could determine the data type of an
arbitrary PMC and whether there were any pre-built Windows binaries of
Parrot available. Leon Brocard pointed him at the "typeof" operator in
answer to the first question but punted on the second. Leo T�tsch also
pointed at "typeof". David noted that it didn't seem to be available in
his 0.0.9 installation and was recommended to use the CVS version, and
discussion drifted toward wondering when Parrot 0.1.0 would see the
light of day. (Not before at least one of either objects or exceptions
is implemented apparently).
Nobody answered the 'pre built Windows binary' part of David's question.
<http://makeashorterlink.com/?I59315AA3>
More on optimizing the JIT with IMCC
In last week's summary I mentioned that Sean O'Rourke had suggested
getting IMCC to store a control flow graph in bytecode, which the JIT
could use to optimize things more effectively. Sean read this and
pointed out that it wasn't his idea but was actually an area of active
research and gave a pointer to some information. He also pointed to a
USENIX paper which discussed adding a full data-flow compiler into a JVM
which could then generate code that ran faster than a lightweight JIT,
especially for long-running programs. Sean's original link was to a
subscription only site but Jason 'Research wants to be free' Gloudon
found a public version of the paper. Dan was fascinated, but was worried
about availability of engineering time, not wishing to presume on Leo,
Daniel and everyone who's done JIT work.
Dan said that he'd 'rather have a lower-overhead JIT with a win for
shorter programs than a high-overhead one with a win for long-running
programs'. Leo pointed out that, at the moment we already have a high
overhead JIT with most of the cost paid at load time and showed some of
these costs. Dan and Leo then discussed what kind of metadata would be
needed from IMCC (or some external tool) in order to improve matters.
Meanwhile, the original 'Using IMCC as JIT optimizer' thread continued
as Leo committed some more changes both to code and to the documentation
in jit.pod. The new version of the JIT optimizing IMCC should be
platform independent and apparently runs 95% of Parrot's tests on an
i386.
Phil Hassey wondered why we even had a set number of registers in the
JVM in the first place. He wondered if it would be possible to have each
block of code declare 'I need 12 registers for this bloc' and let the
JIT system do the appropriate register spilling magic with the system
registers. Leo said that this is approximately what the JIT optimizer
does at the moment and outlined some of the problems associated with it.
Angel Faus had some questions and suggestions about the optimization
approach that Leo was taking, with particular reference to the amount of
copies to and from memory and proposed an efficient way forward.
Nicholas Clark wondered if some of Angel's suggestions mean that imc
(IMCC source code) had now usurped the role of parrot bytecode and
muttered something about premature optimization and the lack of objects,
exceptions, IO or a Z-code interpreter. Leo bridled slightly at
'premature optimization' and wondered what was important about a Z-code
interpreter ('Z-code interpreter' is, according to Nicholas, 'obfuscated
shorthand for "dynamic opcode libraries" and "reading foreign
bytecode".')
Toward the end of the week, Leo checked in a final patch related to this
experiment and commented that, to do things *right*, JIT optimization
should move in the direction that Angel Faus had outlined.
<http://makeashorterlink.com/?I2A312AA3>
<http://makeashorterlink.com/?N2B316AA3> -- Sean's first link
<http://makeashorterlink.com/?S2C341AA3> -- 'Free' paper
<http://makeashorterlink.com/?V2D352AA3> -- IMCC as JIT Optimizer thread
<http://makeashorterlink.com/?V2E314AA3> -- Leo's Last (-Oj) patch
Parrot 0.0.10 freeze
Steve Fink announced that it had been brought to his attention that we
were overdue for another release and announced that he'd like to have a
Parrot feature freeze on March 8, with a Parrot 0.0.10 release a week
after that (or a Parrot 0.1.0 release if someone sneaks objects or
exceptions in under the wire...).
Jerome Quelin wondered about a codename and Benjamin Goldberg commented
that 'we don't have any of objects, exceptions, or a real IO system' and
suggested that we use 'Kakapo', which is a large, flightless parrot.
Garret G�bbel suggested the rather wonderful 'Orange Juice' in homage to
Leo's recent work on the "-Oj" JIT optimization switch.
<http://makeashorterlink.com/?T6F313AA3>
Dan's plans
Dan outlined his plan for the string rework (discussed last week).
Nobody said anything, maybe they liked it.
Dan also outlined some requirements for the final Parrot build system,
again, nobody comment.
And, right at the end of the week, he released his second attempt at an
object spec. This one definitely got comments, but I'll cover them in
the next summary.
<http://makeashorterlink.com/?J10461AA3> -- Strings
<http://makeashorterlink.com/?L31464AA3> -- Builds
<http://makeashorterlink.com/?L22455AA3> -- Objects
PSteve Peters' Patches Prevent Parrot Peeves
Steve Peters released a flurry of patches to eliminate compilation
warnings during Parrot compilation. Leo wasn't sure about one of them,
but I assume that most of them will be applied at some point.
Meanwhile, in perl6-language
Things were even quieter than last week with all of 10 messages, one of
which was last week's summary.
Arrays, lists, referencing
Paul Johnson had observed that changing the order of evaluation (of
terms in a list) -- which is currently undefined in theory whilst being
left to right in practice -- would almost certainly break a great deal.
He suggested that it would be sensible for Perl 6 to define such an
order.
Larry agreed, commenting that 'The fact that Perl 5 doesn't define it is
merely an oversight, brought on no doubt by a lack of oversight. But as
you point out it can deduced by observation of all the various
implementations of Perl.' Which made at least one person smile.
Predefined properties/traits/etc.
Last week, Simon Cozens asked that someone 'please compile a list of all
the "is foo" properties that have been suggested/accepted as being
pre-defined by the language.' as he couldn't keep track of them all.
This week someone (who also happened to be Simon Cozens) did just that.
Allison Randal went through Simon's list commenting on what he'd got
right and wrong, and explaining the general rule (properties and traits
are lower case, class names are capitalized, so "is Foo" mean that
something is a 'Foo', while "is bar" relates to a 'bar' property). The
rest of the thread was taken up with confusion between Munich and
Zurich.
<http://makeashorterlink.com/?V13424AA3>
Acknowledgements, Announcements and Apologies
I'm getting the feeling of someone sat in the calm before the storm.
perl6-language has been very quiet these last few weeks, I'm guessing
that people don't want to distract Larry from the important business of
producing an Apocalypse. Rumours abound of a draft in circulation among
the Perl 6 core design team... Maybe this week will see its publication
and the level of discussion in the language list will rise once more.
Until then I'm enjoying the calm.
Still no American Odyssey web page. One day, I promise.
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 a Schneider 90/5.8 Super
Angulon XL lens 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
