This week on Perl 6 (11/17-11/23, 2002)
by Piers CawleyNovember 27, 2002
And some rough beast, its hour come 'round at last slouches toward...
And then the scansion goes to pot and I can't make a joke fit. Shame.
Anyhoo, it's time for another episode of the continuing saga of Perl 6 development. When I say 'saga' I don't mean a long, long poem of alliterative lines, but a bright, breezy and brisk tale of the bods in the lists. Well, one week mayb, when we've been quiet...
We start, as usual with the internals list.
C#/Parrot Status
Rhys Weatherley, who has been absent from the internals list lo these many days popped up again to ask about:
- Object/class support
- Fixed-size integers and/or conversion opcodes
- Embedding of binary extension sections
He noted that "Not Done Yet" was an acceptable answer. Which is good, because, as Leopold Tötsch pointed out, none of them were done yet. Leo also reckoned that a start would be to implement fixed size integers and conversion ops, and asked for details of what was wanted. Iacob Alin wondered if the various types would be PMCs (answer: Only those types which don't easily map to native types.) Florian Weimer wondered about trapping integer arithmetic. Dan says these will be handled using Parrots standard exception handling mechanism (which doesn't actually exist yet, but signs in the wind suggest we might be getting a Halt and Catch Fire op to raise an exception).
http://groups.google.com/groups
Parrot 0.0.9 status
According to Steve Fink: "The basic status is that lots of people, many of them coincidentally named Leopold Tötsch, have been fixing zillions of things and implementing a number of new features. Nearly everything needed for 0.0.9 has happened, and a lot else besides."
See his post for details of what's still to be done.
One of the most important items was that the tinderbox (a fleet of machines that constantly make, test and remake the latest parrot builds) was a beautiful shade of orange and red, which led to discussion of what was going on (since most people's home boxen seem to be making and testing okay...) Various remedies and patches were tried, but I believe the tinderbox is still mostly the wrong colour.
http://groups.google.com/groups
http://groups.google.com/groups
Unified core.jit
Leopold Tötsch posted an RFC in which he proposed writing a
universal core.jit which provides the basic JIT framework and which
delegates the generation of native ops to processor specific
implementations. Daniel Grunblatt liked the basic idea, but thought
there might be a case for creating cisc.jit and risc.jit to
avoid piles of #ifdefs. Daniel, Leo and Nicholas Clark then spent a
few posts thrashing out issues to do with parameter naming and other
more or less arcane things.
http://groups.google.com/groups
Native Function calls
Dan announced that he'd redone the native function call interface and
had added a new op, bnc, which stands for `build native call'. His
post has the details of how it all works (and how to use it). Well,
that's what he said at first, but apparently it's not true. What he's
actually done is altered the dlfunc opcode to behave like bnc he
described. (It's a shame you can't hit s/bnc/dlfunc/ in your mailer
and have the world alter every single copy of the mail you just
sent. It would have been useful for some of my previous summaries.)
Brent Dax wondered if this was going to be the new XS or if there was more coming. Answer: Sort of.
Leo Tötsch didn't like nci.c's string functions, and wondered too about places where you'd need to pass a pointer to the parrot interpreter. Dan doesn't like the string functions either, noting that the code is "evil, crufty [and] embarrassing", but that it is at least "well encapsulated, so it can be ripped out, shot, and replaced with something elegant and fast at some point in the future." As for parrot interpreter pointers, Dan reckons that any code that needs to go so far should install real extension sub PMCs.
Gopal V worried about the type safety (it's an obsession of his apparently) or rather the complete lack of it, in this interface. Dan, in a quote of the week post said yup, of course it's totally type unsafe and he liked it that way, before confessing that he was getting that `XML feeling. (You know the one--"It seemed like a good idea until I thought about it")' and started backpedalling. Gopal V made a few suggestions, and that's about where we left it.
http://groups.google.com/groups
http://groups.google.com/groups -- the correction
Leopold Tötsch, still the patch monster
Leo's contributions this week include:
- Patches to the JIT which give a 370% speedup in mops_p.pasm
- Patched strings to try and fix a GC issue.
-
More patches to the JIT to tidy things up
This patch set also added i386 support for JITted floating point, which apparently makes mandel.pasm at least 10 times faster.
And that's not counting his contributions in other threads. Once again, I wonder where he finds the time.
Other patches this week from other keyboards that Leo's:
-
Op restarts
Jason Gloudon's patch adds a new control flow flag to op.h to mark which ops can cause interpreter restarts. This information can apparently be used to improved performance in JITted code by removing the need for unnecessary checks.
-
Function <=> Data Pointer casts in nci.h
Josh Wilmes's patch to try and correct warnings on some compilers (and 'outright breakage on tcc'). Steve Fink seemed to like it, and produced an updated version and Dan suggested that they don't worry about it too much right now as he was in the process of redoing nci.c anyway.
- Befunge now supports PerlArray's push/pop
Jerome Quelin is one of the "let's implement a bunch of languages on Parrot" crew, and his pet language is Befunge. If you don't know about Befunge, you're lucky, but if you don't want to stay lucky, Google will probably be depressingly informative. Anyhow, Jerome has now rewritten his Befunge interpreter to use PerlArray's push and pop rather than his older, hand crafted Parrot assembler routines. Dan committed the patch `with the appropriate amount of fear'. -
The return of Leon Brocard
As regular listeners will know, I try to mention Leon Brocard at least once a week. This has been tricky of late because Leon had been on holiday. And when he returned he didn't actually say that much.
This week, he rectified that and offered a couple of patches, and a minor dilemma. The first simply improves a set of error messages, making it easier to track a couple or three problems down. However, his second patch is a little trickier.
The thing is, Leon has implemented another programming language for Parrot. He'd posted it to the list some time ago (before my time as a summarizer I think), but it'd got out of sync with the state of the avian, so this time he offered it as a patch with its own subdirectory of languages. "So? What's the problem?" I hear you ask. The problem is the name of this language, which some people may find offensive. In a postscript to the patch, Leon suggests that a bit of creative misspelling may be in order, so I'll go that route:
Last week, Leon Brocard posted a patch implementing a brianfuck interpreter.
There, that was easy wasn't it?
Coo, what a remarkably long section with no associated links.
Pages: 1, 2 |
