Re: All tests successful considered harmful
chromatic [EMAIL PROTECTED] writes: On Thu, 2005-10-27 at 10:26 -0700, jerry gay wrote: we're missing some parts of a testing framework. we don't have the ability to write test files in PIR, so we're dependent on a perl install for testing. perl's a great language for writing tests anyway, and right now we're dependent on perl for parrot's configure and build as well. that said, breaking this dependency will make parrot just a bit closer to standing on its own. We have a Test::Builder port in PIR. I will move up my plan to port Parrot::Test to use it. Somewhere I have the beginnings of an xUnit style 'parrotunit' testing framework, but that was written ages ago, so I'd need to start it again, but it wasn't that hard to implement. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/
Re: loadlib and libraries with '.' in the name
Joshua Juran [EMAIL PROTECTED] writes: On Sep 23, 2005, at 3:47 AM, Leopold Toetsch wrote: On Sep 23, 2005, at 7:51, Ross McFarland wrote: i was planning on playing around with gtk+ bindings and parrot and went about looking around for the work that had already been done and didn't turn anything up. if anyone knows where i can find it or who i should talk to i would appreciate that info as well. Google for NCI gtk. There is also a weekly summary entry but the xrl.us shortcut seems to have expired. I was wondering about that. I Googled for tinyurl considered harmful and was surprised to find only one message, discussing the phishing risks. I found no mention of the risk of outsourcing a bottleneck to a third party who has zero obligation or direct interest to continue providing the service. From http://metamark.net/about#expire: Do Metamark links expire? The Metamark urls expire after five years or two years after the last usage - whichever comes later. However, if a link is never used, it will expire after two years. This should mean that as long as a link is on a public page, some search engine will visit it and keep it alive. Of course, this is subject to change and is no promise but just my intentions as of this writing. If you want guarantees you can make your own service. To be quite frank, I'm astonished the practice exists here in the first place. In my opinion it goes directly against the spirit of the Web envisioned by Tim Berners-Lee. A better practice would be to post long URL's within angled brackets. And there's no reason you can't do both, either. Which is why the archived summaries at deve.perl.org and perl.com all use the long form URLs. The metamarked URLs only ever appear as a convenience for readers on the mailing list. I am not about to start polluting my mailed summaries with such monstrosities as http://groups.google.com/[EMAIL PROTECTED] any time soon. You're welcome to write your own summaries that do use the full URLs of course. Or, if it bothers you that much, write something to run from cron once a month or so that grabs shortened summary URLs and does a simple GET on them. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/
Re: Summarizer Suggestion...
Matt Fowles [EMAIL PROTECTED] writes: Will~ On 7/6/05, Will Coleda [EMAIL PROTECTED] wrote: It would be nice if the summarizers also summarized the various Planet RSS feeds of journal entries, if those entries were sufficiently relevant. I would be willing to do that, but I can't speak for Piers... From the various journal entries I've ready, they often stand pretty well as summaries anyway. Which is why, in my last summary, instead of summarizing journals I simply pointed to planetsix -- I presume there are others.
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
Chip Salzenberg [EMAIL PROTECTED] writes:
On Wed, Jun 08, 2005 at 10:26:59PM +0100, The Perl 6 Summarizer wrote:
Loop Improvements
Oh no! It's the register allocator problems again. One of these days I
swear I'm going to swot up on this stuff properly, work out whether it's
really the case that full continuations break any conceivable register
allocator and summarize all the issues for everyone in a nice white
paper/summary.
It's not really that complicated. It just takes a long time to explain.
-- Dr. Howland Owll, on SubGenius doctrine
Consider this code:
sub example1 {
my $a = foo();
print $a;
my $b = bar();
print $b;
}
It's obvious that $a and $b can be allocated the same register because
once $b has been set, $a is never used again.
(Please ignore that $a and $b are variables that can't be stored
purely in registers. The real world case that I'm illustrating deals
with temporaries and other values that lack user-visible names. But
the issue is best illustrated this way.)
Now consider this:
sub example2 {
my $a = foo();
do {
print $a;
$b = bar();
print $b;
} while ($b);
}
You can see that it's now *not* OK to allocate $a and $b to the same
register, because the flow of control can jump back to the print $a
even after $b is assigned.
Look at the first function again, and consider what happens if foo
captures its return continuation _and_bar_invokes_it_. It would
effectively amount to the same issue as example2:
sub foo {
$a = 1;
foo();
_implicit_label_for_return_continuation:
print $a;
$b = bar();
print $b;
}
bar() {
if rand() 0.5 { goto _implicit_label_for_return_continuation }
return lucky;
}
Therefore, register allocation must allow for implicit flow of control
from *every* function call to *every* function return ... or, more
precisely, to where *every* continuation is taken, including function
return continuations.
Buf if you fallow the calling conventions that looks like:
sub foo {
$a = 1.
$c = 10;
print $c
save_dollar_a_and_only_dollar_a_because_im_going_to_use_it_after_this_function_call
foo()
_implicit_label_for_return_continuation:
restore_dollar_a
_ooh_i_dont_have_to_save_anything
$b = bar()
_nor_do_i_have_to_restore_anything
print $b
}
That's what caller saves means. You only have to save everything that you're
going to care about after the function returns. You don't have to save the
world, because if it was important it's already been saved further up the call
chain.
This means, of course, that the continuation needs to save the state of the
restore stack, but I thought we already knew that.
Of course, if you're going to actually use GOTO to get to some label that you
should only get to via a continuation (as you do in the code example) then you
deserve to get everything you've got coming to you. A continuation must contain
everything needed to restore the user registers to the correct state no matter
how many times they were taken.
I really don't see how this affects register allocation; the call to bar
doesn't need to save $a because it's not referred to (lexically) after the call
returns. So what if the call to bar might take a continuation. Taking that
continuation should be exactly equivalent to returning from the call to
foo. You really have to stop thinking of continuations as gotos.
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
Matt Fowles [EMAIL PROTECTED] writes: Chip~ On 6/12/05, Chip Salzenberg [EMAIL PROTECTED] wrote: I'd like like to note for other readers and the p6i archives that Piers has failed to grasp the problem, so the solution seems pointless to him. I'm sorry that's the case, but I've already explained enough. This response worries me firstly because of its rudeness and second because of the problem itself. As I see it there are four possibilities a: 1) Chip is right, Piers is wrong. This is a complex problem and refusing to explain it means that others will doubtless also misunderstand it, which you have a chance to preempt here. 2) Chip is wrong, Piers is right. This is a complex problem and refusing discussion on it would be a costly mistake. 3) Chip is right, Piers is right. The two of you have are working from a different base set of definitions/axioms or misunderstood each other in some other way. 4) Chip is wrong, Piers is wrong. Shutting down open conversation so forcefully and caustically will prevent discussion in the future and this problem will continue to haunt parrot as no viable solution has been seen. Regardless of which of these possibilities is true. I see a need for more discussion of this issue. Preferably a discussion that does not degrade into backhanded insults. I have my own ideas about this problem, but I will save that for another response. Don't worry Matt, we're still talking. It takes more than sarcasm to stop me.
Re: Objects, classes, metaclasses, and other things that go bump in the night
Dan Sugalski [EMAIL PROTECTED] writes: At 11:13 AM +0100 12/14/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: subclass - To create a subclass of a class object Is existing and used. Right. I was listing the things we need in the protocol. Some of them we've got, some we don't, and some of the stuff we have we probably need to toss out or redo. add_parent - To add a parent to the class this is invoked on become_parent - Called on the class passed as a parameter to add_parent What is the latter used for? To give the newly added parent class a chance to do some setup in the child class, if there's a need for it. There probably won't be in most cases, but when mixing in classes of different families I think we're going to need this. The chap who's writing Ruby on Rails, a very capable framework reckons that some of these 'meta' method calls that Ruby has in abundance have really made his life a lot easier; they're not the sort of things you need to use very often, but they're fabulously useful when you do.
Re: continuation enhanced arcs
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: ... While S registers hold pointers, they have value semantics. Is that guaranteed? Because it probably needs to be. It's the current implementation and tested. This would restore the register contents to the first state shown above. That is, not only I and N registers would be clobbered also S registers are involved. That's correct. What's the problem? Okay, you've created an infinite loop, but what you're describing is absolutely the correct behaviour for a continuation. Ok. It's a bit mind-twisting but OTOH it's the same as setjmp/longjmp with all implications on CPU registers. C has the volatile keyword to avoid clobbering of a register due to a longjmp. Above code could only use P registers. Or in other words: I, N, and S registers are almost[1] useless. No they're not. But you should expect them to be reset if you take a (full) continuation back to them. The problem I have is: do we know where registers may be reset? For example: $I0 = 10 loop: $P0 = shift array dec $I0 if $I0 goto loop What happens if the array PMC's Cshift get overloaded and does some fancy stuff with continuations. My gut feeling is that the loop might suddenly turn into an infinite loop, depending on some code behind the scenes ($I0 might be allocated into the preserved register range or not depending on allocation pressure). Second: if we don't have a notion that a continuation may capture and restore a register frame, a compiler can hardly use any I,S,N registers because some library code or external function might just restore these registers. This is, of course, why so many languages that have full continuations use reference types throughout, even for numbers. And immutable strings...
Re: continuation enhanced arcs
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Further to my last response. If you have things set up so that you can return multiple times from the same function invocation then the return continuation should have been replaced with a full continuation before the first return, so even the first return will use copying semantics, and the registers will always be restored to the state they were in when the function was first called, which is absolutely the right thing to do. Here is again the example I've brought recently. Please go through it and tell me what's wrong with my conclusion. $I0 = 42 # set I16, 42 42 $N0 = 2.5# set N16, 2.5..101... $S0 = a# set S16, a0x1004 - a $P0 = a# set P16, a0x2008 - a loop: foo()# set P0, ...; invokecc We have some temporary variables and a function call. Variables are used beyond that point, so the register allocator puts these in the preserved register range. The function Cfoo() might or might not capture the continuation created by the Cinvokecc opcode. Let's assume, it is captured, and stored into a global, if it wasn't already, i.e. the first time. According to Dan's plan, the function return restores the register contents to the state of the creation of the return continuation, which is shown in the right column. $I0 += 1 # add I16, 1 43 $N0 *= 2.0 # mul N16, 2.0.101 $S0 .= b # concat S16, b 0x1008 - ab inc $P0 # inc P16 0x2008 - b dec a# dec P17 0x200c - 1 if a goto loop # if P17, loop A note WRT strings: the concat might or might not assign a new string to S16. It depends on the capacity of the string buffer. But generally: string operations do create new string headers with a different memory address like shown here. While S registers hold pointers, they have value semantics. Is that guaranteed? Because it probably needs to be. Now we loop once over the function call. This creates a new return continuation and on function return registers are restored to their new values (44, 10.0, abb, c). All fine till here. The loop counter a reaches zero. Now the next instruction is another function call. bar()# set P0, ... invokecc The bar() function extracts the return continuation captured in the first call to foo() from the global and invokes it. Control flow continues right after the invokecc opcode that called foo(). This would restore the register contents to the first state shown above. That is, not only I and N registers would be clobbered also S registers are involved. That's correct. What's the problem? Okay, you've created an infinite loop, but what you're describing is absolutely the correct behaviour for a continuation. If you need any state to be 'protected' from taking the continuation then it needs to be in a lexical or a mutated PMC. This is just how continuations are supposed to work. Above code could only use P registers. Or in other words: I, N, and S registers are almost[1] useless. No they're not. But you should expect them to be reset if you take a (full) continuation back to them. Presumably if foo() doesn't store a full continuation, the restoration just reuses an existing register frame and, if foo has made a full continuation its return does a restore by copying?
Re: continuation enhanced arcs
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Matt Fowles [EMAIL PROTECTED] wrote: Thanks for the clear explanation. I did not realize that S registers could switch pointers, that does make things a little harder. I have a recommendation for a possible hybrid solution. Incur the cost of spilling I,S,N registers heavily. Restore the state of P register. My conclusion was that with the copying approach I,S,N registers are unusable. But you only need to copy when the frame you're restoring is a full continuation Yes. With the effect that semantics of I,S,N (i.e. value registers) suddenly changes. I'd submit that, in the vast majority of cases you're not going to be dealing with full continuations, and on the occasions when you are the programmer using them will be aware of the cost and will be willing to pay it. *If* the programmer is aware of the fact that a subroutine can return multiple times, he can annotate the source so that a correct CFG is created that prevents register reusing alltogether. The problem is gone in the first place. *If* that's not true, you'd get the effect that suddenly I,S,N registers restore to some older values which makes this registers de facto unusable. But they're bloody value registers. They're *supposed* to restore to the state they were in when the function was originally called. Which is what copying semantics does.
Re: continuation enhanced arcs
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Matt Fowles [EMAIL PROTECTED] wrote: Thanks for the clear explanation. I did not realize that S registers could switch pointers, that does make things a little harder. I have a recommendation for a possible hybrid solution. Incur the cost of spilling I,S,N registers heavily. Restore the state of P register. My conclusion was that with the copying approach I,S,N registers are unusable. But you only need to copy when the frame you're restoring is a full continuation Yes. With the effect that semantics of I,S,N (i.e. value registers) suddenly changes. I'd submit that, in the vast majority of cases you're not going to be dealing with full continuations, and on the occasions when you are the programmer using them will be aware of the cost and will be willing to pay it. *If* the programmer is aware of the fact that a subroutine can return multiple times, he can annotate the source so that a correct CFG is created that prevents register reusing alltogether. The problem is gone in the first place. *If* that's not true, you'd get the effect that suddenly I,S,N registers restore to some older values which makes this registers de facto unusable. Further to my last response. If you have things set up so that you can return multiple times from the same function invocation then the return continuation should have been replaced with a full continuation before the first return, so even the first return will use copying semantics, and the registers will always be restored to the state they were in when the function was first called, which is absolutely the right thing to do.
Re: continuation enhanced arcs
Leopold Toetsch [EMAIL PROTECTED] writes: Matt Fowles [EMAIL PROTECTED] wrote: Thanks for the clear explanation. I did not realize that S registers could switch pointers, that does make things a little harder. I have a recommendation for a possible hybrid solution. Incur the cost of spilling I,S,N registers heavily. Restore the state of P register. My conclusion was that with the copying approach I,S,N registers are unusable. But you only need to copy when the frame you're restoring is a full continuation (and, actually, if copy on write works at a per register level, copy on write might be the way to go). If it's a return continuation you can simply use the stored state. I'd submit that, in the vast majority of cases you're not going to be dealing with full continuations, and on the occasions when you are the programmer using them will be aware of the cost and will be willing to pay it.
Re: continuation enhanced arcs
Luke Palmer [EMAIL PROTECTED] writes: Piers Cawley writes: I'd submit that, in the vast majority of cases you're not going to be dealing with full continuations, and on the occasions when you are the programmer using them will be aware of the cost and will be willing to pay it. Yeah probably. Except the problem isn't the cost. The problem is the semantics. If you copy the registers, then when you invoke the continuation, their *values* restore to what they were when you made the continuation. These are not proper semantics, and would result in subtle, incorrect infinite loops. PMCs don't relocate, so the values you're restoring are simply the addresses of said PMCs. The Numeric registers are value registers anyway so no problem there (since there's no way of making a pointer to the contents of such a register AFAICT). I'm not sure about string registers. And anyway, copying is how it used to work, and work it did, albeit slowly.
Re: continuation enhanced arcs
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: We don't have a problem WRT register preservation, the problem arises due to register re-using. Ah! [a light goes on over Piers's head]. Or am I missing something fundamental? I don't know ;) I was. Hmm... bugger. So, unless we make the register allocator solve the halting problem, the rule becomes If you're playing silly beggars with continuations and you're expecting to get at something in a 'surprising' way, stuff it in a lexical or we guarantee that you will be anally violated by an enraged waterbuffalo that's just sick to death of non-determinism? This would make quite a fine explanation in the docs, except that's a bit unclear about stuff *it*. The waterbuffalo is concerned of preserved *temporary* variables too. I just thought of a heuristic that might help with register preservation: A variable/register should be preserved over a function call if either of the following is true: 1. The variable is referred to again (lexically) after the function has returned. 2. The variable is used as the argument of a function call within the current compilation unit. Condition 2 is something of a bugger if you have big compilation units, but register allocation is always going to be a pain when there are big compilation units around.
Re: continuation enhanced arcs
Okay, I'm confused, I thought that the whole point of a caller saves, continuation passing regime was that the caller only saves what it's interested in using after the function returns. Exactly *where* that return happens, and whether it happens more than once, is completely irrelevant from the point of view of the caller. ISTM that the register allocator should work on the principle that anything it didn't save before it made the call will be toast afterwards. Doing anything more sophisticated than optimizing register allocation on a sub by sub basis seems like a license for getting completely and utterly plaited. Or am I missing something fundamental?
Re: Closures and subs
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Klaas-Jan Stol [EMAIL PROTECTED] wrote: Hello, I've been playing with closures and subs but I have a little bit of trouble with those. newsub $P0, .Closure, _foo $P0(q) newsub $P0, .Closure, _foo $P0(q) Closures have to be distinct. Does this *really* mean that, if I create a closure in a function and return it to my caller, that closure can only be invoked once? No, it can be invoked as often you like. But above case seems to be different and very similar to what I already asked: (define (choose . all-choices) (let ((old-fail fail)) (call-with-current-continuation You remember that snippet, it's now a test in t/op/gc.t. I had to insert the line below XXX and use a second closure, which has the arr2 in it's context. newsub choose, .Closure, _choose x = choose(arr1) # XXX need this these closures have different state newsub choose, .Closure, _choose y = choose(arr2) The question was, if that's technically correct. Ah... of course, I was asking a stupid question. Always the most plausible hypothesis I think. -- Piers Oh, predicting the future's easy, you just make a continuation at the point you're asked, say anything and head off into the future to find what happens, then take the continuation back to the question and give a more accurate answer. -- me in #parrot
Re: Why is the fib benchmark still slow - part 1
Miroslav Silovic [EMAIL PROTECTED] writes: Leopold Toetsch wrote: I believe that you shouldn't litter (i.e. create an immediately GCable object) on each function call - at least not without generational collector specifically optimised to work with this. The problem isn't the object creation per se, but the sweep through the *whole object memory* to detect dead objects. It's of course true, that we don't need the return continuation PMC for the fib benchmark. Well, creation is also the problem if you crawl the entire free heap before triggering the next GC round. You get a potential cache miss on each creation and on each mark and on each destruction. To keep GC out of the way, the entire arena has to be confined to cache size or less. But a HLL translated fib would use Integer PMCs for calculations. Hmm, I'm nitpicking here, but it's not how e.g. Psyco works. It specialises each function to specific argument types and recompiles for each new argument type set. Assuming that you'll call only very few functions with more than 1-2 type combinations, this is a good tradeoff. It also removes a lot of consing, especially for arithmetics. ... This would entail the first generation that fits into the CPU cache and copying out live objects from it. And this means copying GC for Parrot, something that (IMHO) would be highly nontrivial to retrofit. A copying GC isn't really hard to implement. And it has the additional benefit of providing better cache locality. Nontrivial to retrofit or not, we need a generational GC. The catch with generation GC is that, once you have guaranteed destructors being called promptly, you still have to sweep the whole arena every time you leave a scope.
Re: Closures and subs
Leopold Toetsch [EMAIL PROTECTED] writes: Klaas-Jan Stol [EMAIL PROTECTED] wrote: Hello, I've been playing with closures and subs but I have a little bit of trouble with those. newsub $P0, .Closure, _foo $P0(q) newsub $P0, .Closure, _foo $P0(q) Closures have to be distinct. Does this *really* mean that, if I create a closure in a function and return it to my caller, that closure can only be invoked once? If it does, this is slightly more broken than a very broken thing.
Re: Are we done with big changes?
Jeff Clites [EMAIL PROTECTED] writes: On Nov 1, 2004, at 6:14 AM, Dan Sugalski wrote: Because I need to get strings working right, so I'm going to be implementing the encoding/charset library stuff, which is going to cause some major disruptions. Please tag cvs before checking this in. Release candidate?
Re: [CVS ci] indirect register frames 14 - cache the register frame
Dan Sugalski [EMAIL PROTECTED] writes: At 2:30 PM -0500 11/2/04, Matt Fowles wrote: All~ I don't like the idea of having to dig down through the entire return chain promoting these guys. Is there a reason not to use DOD/GC to recycle continuations? Yes. Speed. While you can skip some of the digging (since you can stop at the first promoted one) the reality is that 90%+ of the return continuations will *never* need promoting. Not bothering to make the return continuations true full continuations until they're actually needed as one lets us immediately recycle return continuations as soon as they're used in the near-overwhelming majority of the cases -- that is, when nothing can possibly have a hold of 'em. That leaves a lot fewer objects for the DOD to sweep through, as well as speeding up allocation (since we're more likely to have ones at hand, and likely in cache too) of the things in the first place. And, dammit, making a full continuation isn't something a programmer should do lightly.
Re: [pid-mode.el] cannot edit
Stéphane Payrard [EMAIL PROTECTED] writes: On Fri, Oct 01, 2004 at 06:09:37PM +0200, Jerome Quelin wrote: Hi, I tried the pir-mode provided in the editor/ subdir. And when opening a .imc file (I've associated .pir with pir-mode + font-lock-mode), I cannot type spaces or carriage returns: (24) (warning/warning) Error caught in `font-lock-pre-idle-hook': (invalid-regexp Invalid syntax designator) And the minibuffer tells me: Symbol's function definition is void: line-beginning-position I'm using xemacs 21.4.14 Is the pir-mode.el file complete? Or am I encountering a bug in it? This function is defined in emacs: line-beginning-position is a built-in function. (line-beginning-position optional N) Return the character position of the first character on the current line. With argument N not nil or 1, move forward N - 1 lines first. If scan reaches end of buffer, return that position. The scan does not cross a field boundary unless doing so would move beyond there to a different line; if N is nil or 1, and scan starts at a field boundary, the scan stops as soon as it starts. To ignore field boundaries bind `inhibit-field-text-motion' to t. This function does not move point. switch to emacs. :) Or patch pir-mode.el, your choice.
Re: Continuation re-invocation
Jeff Clites [EMAIL PROTECTED] writes: Two questions: 1) Is it supposed to be possible to invoke a given continuation more than once, or is it used up once invoked? Yes, you should be able to invoke one more than once. 2) Am I supposed to be able to jump down the stack by invoking a continuation? To be specific, if A calls B calls C, and C invokes the return continuation which takes it directly back to A, can something later invoke the return continuation which leads to B? (Emphasizing there the notion that something skipped over a continuation, then later came back and used it.) Yes.
Re: towards a new call scheme
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski wrote: At 4:15 PM +0200 9/23/04, Leopold Toetsch wrote: get_cc(OUT Px) # 1) get current continuation, i.e. the return cont. In a rare, possibly unique burts of opcode parsimoniousness... perhaps this would be a good thing for the interpinfo op. That's fine too. return_cc() # 2) return via current continuation 1) is only needed for special porposes, like passing the continuation on to a different place. The normal way to return from a sub will be 2) If that's in, access to CP1 as a return continuation will be deprecated. Well... should we? We're still passing the return continuation *in* in P1, unless you want to move it out and unconditionally make it a parameter to invoke. Well, basically, if an interpreter template is used (hanging off the subroutine), the previous interpreter template is the return continuation. That means that for the usual case (function call and return) there isn't any need to construct a return continuation and put it somewhere. The return continuation would only be needed to create a real continuation out of it and pass it along somewhere. If that calling scheme doesn't fly, its still better to have specific locations in the interpreter context that hold the sub and the return continuation to allow simple function backtrace for the error case or introspection. That's currently not possible, because P0 and P1 can be swapped out into the register backing stack and reused to hold something totally different. I think I'd also like to make a change to sub invocation, too, to allow passing in alternate return continuations, which makes tail calls easy. Ok. Good point. We could get rid of Cinvoke Px (call the sub in Px w/o calling conventions) in favor of Cinvoke_with_retc Px. Anyway, the visible part of a return continuation (in above opcode or Cget_cc would be a continuation. The normal case (call/return) could just have that continuation internally in the context. No additional PMC is constructed ifn't needed. I could be wrong here, but it seems to me that having a special 'tailinvoke' operator which simply reuses the current return continuation instead of creating a new one would make for rather faster tail calls than fetching the current continuation out of the interpreter structure, then invoking the target sub with with this new continuation (ISTM that doing it this way means you're going to end up doing a chunk of the work of creating a new return continuation anyway, which rather defeats the purpose.)
Re: Numeric semantics for base pmcs
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Nope -- we don't have bigints. :) Pardon, sir? We've got the big number code, but I don't see much reason to distinguish between integers and non-integers at this level -- the only difference is exponent twiddling. Ah, ok. BigInt as a degenerated BigNum. I still prefer the notion that adding or multiplying to integers give a BigInt on overflow. While at num vs int: do we automatically downgrade to int again? 6.0/2.0 = 3.0 or 3 ? No. Once a real, always a real. I see no harm in collapsing appropriate rationals to ints mind...
Re: Tight typing by default?
Dan Sugalski [EMAIL PROTECTED] writes: It seems pretty clear that the general opinion is that operations should produce the tightest reasonable type for an operation--integer multiplication should produce an integer unless it can't, for example. For our purposes I think the typing should go: platform int-float-bignum with an operation producing a type no tighter than the loosest type in the operation. (so int/float gives a float, float-bignum gives a bignum) This seem reasonable? No. int-bignum-float In other words, floats only happen if you specifically introduce them (or take a square root or something).
Re: The new Perl 6 compiler pumpking
Dan Sugalski [EMAIL PROTECTED] writes: There's not been a big public announcement, so it's time to change that. I'd like everyone to give a welcome to Patrick Michaud, who's volunteered to officially take charge of getting the Perl 6 compiler module written. I've put in yet another nudge to get the parrot-compilers list started, and get the perl6-internals list renamed to parrot-internals (which is what it really is) so we can get things properly sorted out, as I expect Patrick will be digging into the fun stuff pretty darn soon. Mmm... three list to summarize...
Re: This week's summary
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] writes: Piers Cawley wrote: Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] writes: Care to explain what those are, O great math teacher? What's a math teacher? It's the right^H^H^H^H^HAmerican way to say maths teacher. You mean American and 'right' are not equivalent? Wow.
Re: This week's summary
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] writes: The Perl 6 Summarizer wrote: The infinite thread Pushing onto lazy lists continued to exercise the p6l crowd (or at least, a subset of it). Larry said that if someone wanted to hack surreal numbers into Perl 6.1 then that would be cool. Care to explain what those are, O great math teacher? What's a math teacher?
Re: This week's summary
Austin Hastings [EMAIL PROTECTED] writes: --- The Perl 6 Summarizer [EMAIL PROTECTED] wrote: Okay, so the interview was on Tuesday 13th of July. It went well; I'm going to be a maths teacher. [...] As we all know, time flies like an arrow, but fruit flies like a banana. If you found this mathematical summary helpful, please consider paying your tuition you ungrateful little bastards. ** Gurfle **
Re: the whole and everything
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: Leo, we've talked about this before. The sensible and straightforward thing to do in a case like this is to tag in the sub pmc which register frames are used by the sub. And what, if the sub calls another sub? Then the call to the inner sub saves the registers that are used by the inner sub.
Re: The Pie-thon benchmark
Ask Bjørn Hansen [EMAIL PROTECTED] writes: Andy Wardley [EMAIL PROTECTED] writes: Dan Sugalski wrote: it's not exactly exciting watching two people hit return three times in front of a roomful of people. Although watching two people hit each other in the face with custard pies three times in front of a roomful of people may be a lot more fun. Mutter. Mutter. Lack of bloody money. Mutter. Not coming to OSCON. Mutter. Hope someone videos it. Mutter. And sticks it on the web. Mutter. I'm planning to bring a DV camera to OSCON -- and I'm sure others will too. =) - ask ps. Andy, sucks we won't get to see you though! Err... I think you got your quoting wrong; it was me that did the muttering.
Re: Another small task for the interested
Dan Sugalski [EMAIL PROTECTED] writes: On Sun, 20 Jun 2004, Ion Alexandru Morega wrote: Dan Sugalski wrote: I checked in more of PDD 17, detailing parrot's base types. Some of those types definitely don't exist (like, say, the string and bignum type...) and could definitely use implementing. Should be fairly straightforward, and would be a good way to get up to speed on writing PMC classes. Hello, i'm new to this list and to parrot programming, so i decided to start with something simple. I implemented a String PMC that is pretty much complete, it compiles, but i haven't tested it yet. It would be great if someone had a look at it, and later when i write some tests i'll check in a patch. The .pmc is attached. Sorry this one sat so long. (Piers reminded me with the summary) It worked then ' I checked in the PMC. Tests would be cool, to be sure. :)
Re: The Pie-thon benchmark
Andy Wardley [EMAIL PROTECTED] writes: Dan Sugalski wrote: it's not exactly exciting watching two people hit return three times in front of a roomful of people. Although watching two people hit each other in the face with custard pies three times in front of a roomful of people may be a lot more fun. Mutter. Mutter. Lack of bloody money. Mutter. Not coming to OSCON. Mutter. Hope someone videos it. Mutter. And sticks it on the web. Mutter.
Re: [Summary] Help
Piers Cawley [EMAIL PROTECTED] writes: [...] Thanks in advance. And thanks to Sebastian Riedel, Brent Royal-Gordon, Robert Spier and the aforementioned Jeffrey Dik I have filled in my lacunae and I'm ready to get my summary on when Monday rolls around.
Re: [Summary] Help
Piers Cawley [EMAIL PROTECTED] writes: For various annoying reasons involving a pernickety external drive and a service centre that, after more than a week *still* hasn't taken a look at my main machine, I find myself missing a tranche of messages to perl6-internals and perl6-language. If some kind soul were to send me mbox files containing messages in the period from, say, the first of June through to the 17th, then they would have earned my undying gratitude. Thanks in advance. Thanks to Jeffrey Dik's extreme promptness, I now have an archive for perl6-internals and I'm just looking for perl6-language.
Re: PerlHash using PMCs for keys?
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Just use a Key PMC for $P2. So, just for fun I added the following test to t/pmc/perlhash.t: new P10, .PerlHash new P1, .PerlString set P1, Bar new P2, .Key set P2, P1 ^^^ Cset Px, Py aliases the two PMCs, both are pointing to the same PMC then. You'd like to use Cassign here. Of course I would. Oops. new P3, .Key set P2, P1 ^^ typo? Yes, and should be an assign. Perl 6 supports using full on objects as keys in its hashes. It seems that having parrot do the same would be a Good Thing. The main problem here is, what does ... set P0, P1[P2] ... mean: keyed_string or keyed_integer, i.e. hash or array lookup. The Key PMC provides this information, a plain string could be used in both ways: set P2, 42 set P0, P1[P2] It depends of course on the aggregate, what kind of key it would like to use, but e.g. for an OrderedHash PMC, which supports lookup by string *and* by integer, the usage is ambiguous. I'm not advocating removing the key object for disambiguating this sort of thing. We could change Ckey.c:key_integer() to extract a number with Cget_integer from any PMC and do the same with Ckey_string but some keyed usage needs a defined type. I'd argue that at the base level all objects should have a 'hash_int' method (or some other name to be decided) which generates a hash integer appropriate to the object. See countless smalltalk images for such usage.
Re: PerlHash using PMCs for keys?
Leopold Toetsch [EMAIL PROTECTED] writes: Togos [EMAIL PROTECTED] wrote: Should aggregate PMCs (like PerlHash) be able to take PMCs as keys? I mean so that: $P0 = $P1[$P2] Just use a Key PMC for $P2. $P2 = new Key $P2 = key_string ... So, just for fun I added the following test to t/pmc/perlhash.t: new P10, .PerlHash new P1, .PerlString set P1, Bar new P2, .Key set P2, P1 set P10[P2], Food\n set S0, P10[P2] print S0 new P3, .Key set P2, P1 set S1, P10[P2] print S1 end Just to test that two Keys created from the same PMC would fetch the same thing from the hash. Imagine my surprise when the test blew up with 'Key not a string!' before producing any output. Perl 6 supports using full on objects as keys in its hashes. It seems that having parrot do the same would be a Good Thing.
Re: One more thing...
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Then, at runtime, 'fred' gets set up as the implemntation for an op. Which, given your implementation, means that each function call that fred makes should be protected with savetop/restoretop pairs. Oops. The implementation checks register usage of the called sub at *runtime*, or more precisely at first invocation of the sub and caches the value. It would need a notification (similar to the method cache), if the sub got recompiled. Who's talking about recompiling. I'm talking about fred being registered as the handler for some op at runtime. ISTM that, either fred has to get recompiled (assuming the source is kicking about) so that every function call it makes is guarded with a saveall, or you *always* do a saveall as you call fred so that the compiled in, optimized saves will continue to work. With the fingerprint approach I outlined, one can at least avoid the saveall in some cases.
Re: One more thing...
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley wrote: But under this scheme, the implementing function will have to do a saveall for every function it calls because it doesn't know what registers its caller cares about. And you're almost certainly going to want to call other functions to do the heavy lifting for all the usual reasons of code reuse. Yep that's true. As well as with real caller saves. Which leads back to my (almost) warnocked proposal: Consider a sub, call it fred, that calls other subs and only uses PMC registers. At compile time, you wrap those calls in appropriate pushtopp/poptopp pairs. Then, at runtime, 'fred' gets set up as the implemntation for an op. Which, given your implementation, means that each function call that fred makes should be protected with savetop/restoretop pairs. Oops.
Re: One more thing...
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: [ calculating registers to save ] ... once per sub per location where the sub is called from. But there isn't any knowledge that a sub might be called. So the cost is actually more per PMC instruction that might eventually run a PASM MMD. This is, when its done right, or ... No. Once per compilation unit. An example: .sub foo # a lot of string handling code # and some PMCs $P0 = concat $P0, $S0# 1) calculate: save P, S here # now a lot of float code # no strings used any more # and no branch back to 1) $N1 = 47.11 # $N1's live starts here $P0 = $P1 + $N1 # 2) calculate: save P, N regs $P2 = $P0 + $N1 # 3) calculate: save P regs # no N reg used here .end At 1) the caller is not interested in preserving N-registers, these aren't used there. Saving everything, the caller needs saving, ends up with Csaveall in non trivial subroutines. Using your proposal would need a lot of storage for the saved register ranges. If the calculation is done based on the called subroutine, it's not unlikely that only a few registers have to be preserved, e.g. no N-registers for the overloaded Cconcat and no string registers for the overloaded Cadd. This doesn't violate the principle of caller saves: all that needs preserving from the caller's POV is preserved. But under this scheme, the implementing function will have to do a saveall for every function it calls because it doesn't know what registers its caller cares about. And you're almost certainly going to want to call other functions to do the heavy lifting for all the usual reasons of code reuse. I can see a situation where you end up with .sub implementing_function saveall invokecc user_callable_implementing_function restoreall invoke P1 .end .sub user_callable_implementing_function do_this(...) do_that(...) do_the_other(...) ... .end simply because you want to follow good coding practice. You're right that, in the limiting case, my 'fingerprinting' approach is going to reduce to a saveall, but the example you give could be broken up into .sub foo $P0 = stringy_stuff($P0) ($P0, $P2) = floaty_stuff($P0) ... .end which will simply need save P registers (and the called functions will be able to arrange for efficient saves too...)
Re: One more thing...
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Not quite for this case. Or in theory yes, but... As calling the subroutine mustn't have any changes to the caller's registers, it's just simpler to save these registers that the subroutine might change. But generating the save signature for a given sub is a compile time cost that only needs to be paid once for each sub and shoved on an I register ... once per sub per location where the sub is called from. But there isn't any knowledge that a sub might be called. So the cost is actually more per PMC instruction that might eventually run a PASM MMD. This is, when its done right, or ... No. Once per compilation unit. Stick it in a high register and keep it nailed there for the duration of the sub. Specify this register as part of the calling conventions; the right value will then get restored at any function return and there's no need to regenerate it.
Re: One more thing...
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: - if it calls a PASM routine, registers have to be preserved. Which registers depend on the subroutine that actually gets called (ok, this information - which registers are changed by the sub - can be attached to the Sub's metadata) No, we're in caller saves remember. Ok, yes. But MMD and delegated functions are a bit different. The caller isn't knowing that it's a caller. The PASM is run from the inside of the C code. ... The registers that need saving are dependent on the caller. Not quite for this case. Or in theory yes, but... As calling the subroutine mustn't have any changes to the caller's registers, it's just simpler to save these registers that the subroutine might change. ... Since the registers used by a function at any point are statically determined, maybe add's signature could be altered to take an integer 'save flags' argument specifying which registers need to be preserved for the caller, This has a performance penalty for the non-MMD case. I can imagine that overloaded MMD functions are simpler (in respect of register usage) then the caller's code. So it seems that saving, what the MMD sub might change on behalf of the caller is just more effective. But generating the save signature for a given sub is a compile time cost that only needs to be paid once for each sub and shoved on an I register (which could, of course, be standardized). An MMD sub with a PASM implementation simply looks at the appropriate register, saves the right stuff, sets up a return continuation and has the interpreter invoke it. Which leaves a correctly set up continuation chain and a PASM implementation which can do whatever the heck it likes, including making continuations, closures etc that can be returned to multiple times because it got invoked in the normal runloop. The work has to be done either way, but by arranging things so that everything looks like caller saves (and so that there is no MMD barrier to continuations) just seems to make the most sense. BTW, if it's a continuation barrier does that also mean it's an exception barrier?
Re: One more thing...
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: At 11:35 AM +0200 4/30/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: If we go MMD all the way, we can skip the bytecode-C-bytecode transition for MMD functions that are written in parrot bytecode, and instead dispatch to them like any other sub. Not really. Or not w/o significant overhead for MMD functions implemented in C. Well... about that. It's actually easily doable with a bit of trickery. We can either: This still doesn't work. Function calls just look different then plain opcodes like add Px, Py, Pz. - it's not known, if Cadd calls a PASM subroutine - if it calls a PASM routine, registers have to be preserved. Which registers depend on the subroutine that actually gets called (ok, this information - which registers are changed by the sub - can be attached to the Sub's metadata) No, we're in caller saves remember. The registers that need saving are dependent on the caller. Since the registers used by a function at any point are statically determined, maybe add's signature could be altered to take an integer 'save flags' argument specifying which registers need to be preserved for the caller, then if MMD determines that the call needs to go out to a PASM function, the appropriate registers can be saved.
Re: A12: The dynamic nature of a class
chromatic [EMAIL PROTECTED] writes: On Fri, 2004-04-23 at 05:42, Dan Sugalski wrote: Since any type potentially has assignment behaviour, it has to be a constructor. For example, if you've got the Joe class set such that assigning to it prints the contents to stderr, this: my Joe $foo; $foo = 12; should print 12 to stderr. Can't do that if you've not put at least a minimally constructed thing in the slot. (hypothetical pre-breakfasty musings) Such as a PerlUndef with the 'expected_type' property set to 'Joe'? PerlUndef's behaviour is one of the Parroty things that makes me rather nervous. It blurs (obliterates) the line between container and value rather spectacularly. ISTM that declaring 'my Joe $foo' should create a PerlScalar with an expected type of Joe and a PerlUndef as its contents. The PerlScalar's definedness test would simply be a test for the definedness of its contents.
Re: OO benches
Leopold Toetsch [EMAIL PROTECTED] writes: Aaron Sherman [EMAIL PROTECTED] wrote: On Fri, 2004-04-16 at 18:18, Leopold Toetsch wrote: Sorry, I gave the wrong impression. I meant it looks suspiciously like Python is doing a lazy construction on those objects, not that there is anything wrong with the benchmark. No, I don't think that this is happening. Parrot's slightly slower object instantiation is due to register preserving mainly. The __init code is run from inside the new PObj, IClass opcode. As its not known that a method call is happening here, we can't use register preserving operations that only save needed registers--we have to save all registers. These two memcpys are the most heavy part of the operation. Maybe we should rethink that then and make allocation and initialization two different phases. Or dictate that new PObj, IClass should be treated as if it were a function call with all the caller saves implications that go with it.
Re: Attribute questions
Dan Sugalski [EMAIL PROTECTED] writes: At 6:53 PM +0100 4/8/04, Mark Sparshatt wrote: I've got a couple of questions about Atrributes in Parrot. PDD15 says that both classes and objects have a list of attributes and it is possible to add or remove attributes to a class but not an object. Am I right in thinking that the attribute list for an object is just a copy of the attribute list for the class, which is used to store the objects values? It seems that for Ruby instance variables can be modelled using attributes, but I couldn't see any way of handling class variables. So, what is the recommended way of handling them? First, one takes the bat labeled Metaclasses and smacks the designer in the head with it. Then, once enlightenment has hit, we implement metaclasses and you add class variables as new attributes on a class' metaclass. I think. Enlightenment *has* hit then? Alternately you can stick 'em in as plain variables in the class namespace, which is probably the right answer for the moment, though not for the long run. I already (sort of) think of classes and objects as being 'a bit like namespaces', so that makes a certain kind of sense.
Re: This week's Summary
Leopold Toetsch [EMAIL PROTECTED] writes: The Perl 6 Summarizer [EMAIL PROTECTED] wrote: Subroutine calls Leo announced that he's added a pmc_const opcode to parrot. The idea being that, [ ... ] you would instead fetch a preexisting Subroutine PMC from the PMC constant pool. Not quite. I've implemented it here locally and I'm awaiting some comments ;) If it's not obvious from the summary, I think it's a cracking idea.
Re: Behaviour of PMCs on assignment
Leopold Toetsch [EMAIL PROTECTED] writes: Togos [EMAIL PROTECTED] wrote: $I1 = $I2 + $I3 $P1 = $P2 + $P3 Which, of course, doesn't work. But this is what languages like Python or Ruby would expect to be able to do, as they don't need Perl's fancy variable objects -- a register is good enough. sementics of That and other arguments are of course all correct. I just have the gut feeling that having both opcode and vtable variants blows core size up to an isane value. Couldn't you have a single opcode, Cassign_content Pn, Pm, which uses Pn's vtable assignment, and make Cadd $P1, $P2, $P3 etc simply use the 'make a new PMC' thing. That means that, to get the current semantics you'd have to do $P2 = $P3 + $P4 assign_content $P1, $P2 But I'm not sure that's an enormous loss.
Re: Fun with nondeterministic searches
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Remember how Leo wanted an example of how continuations were used? Great example - I don't understand how it wotks though :) - but I understand, why the PIR code might fail: Okay, I'll try and explain it. Great thanks. (I was just going through it and sometimes I have a slight clue how it works (or better I know what's going on but I'm for sure unable to write such a piece of code from scratch (I'm missing some experience with this kind of progamming languages (like lisp et al $P0 = find_lex(fail) $P0() # Why can't we do this? Does $P0.() work any better? It used to give tons of reduce conflicts and wrong code ... wait ... try again ... now it works ... fixed. Oh, cool. $P0.() would be a method call w/o method, i.e. a parser error. Yean, I was thinking analogous to Perl 6's proposed syntax $foo.(...) says to treat $foo as a function reference and call it with appropriate arguments.
Re: Fun with nondeterministic searches
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley wrote: Leopold Toetsch [EMAIL PROTECTED] writes: At (1) the continuation is marked with Cdont_cache_retc. In Csave_context this flag is propagated to the stacks in the continuation's context. At (2) or any other place, where this stacks are popped off, the stack chunks are not put onto the stack chunk freelist. That seems to make sense. And it works (for your code) Here is a proof of concept patchoid: Fabulous 1) change to your example code: $P1 = clone P1 store_lex 1, cc, $P1 (the clone strips off all recycle flags) Oh nice, much neater than what I was thinking of involving making a 'real' continuation and copying context info across from the return continuation. Does this pretty much remove the last distinction between RetContinuation and Continuation?
Fun with nondeterministic searches
Remember how Leo wanted an example of how continuations were used? Well, I ported the following Scheme code to PIR. (The PIR is appended to this message... ;;; Indicate that the computation has failed, and that the program ;;; should try another path. We rebind this variable as needed. (define fail (lambda () (error Program failed))) ;;; Choose an arbitrary value and return it, with backtracking. ;;; You are not expected to understand this. (define (choose . all-choices) (let ((old-fail fail)) (call-with-current-continuation (lambda (continuation) (define (try choices) (if (null? choices) (begin (set! fail old-fail) (fail)) (begin (set! fail (lambda () (continuation (try (cdr choices) (car choices (try all-choices) ;;; Find two numbers with a product of 15. (let ((x (choose 1 3 5)) (y (choose 1 5 9))) (for-each display `(Trying ,x and ,y #\newline)) (unless (= (* x y) 15) (fail)) (for-each display `(Found ,x * ,y = 15 #\newline))) Which (as anyone can plainly see) implements a non deterministic search (and something like it could come in handy when implementing Perl 6 Junctions). I think I've tweaked a bug in the GC somewhere because 'parrot -t choose.imc' and 'parrot -tG choose.imc' fail in different places. Also, I thought Leo's patches to the stacks meant that RetContinuations had been done away with, but the trace output implies otherwise, and it may be that the code is failing because of this difference. The call to fail *should* return to just after the second call to choose by invoking the lexically held continuation, but this isn't what happens Rejigging IMCC to use Continuations instead of RetContinuations (using a simple minded search replace) makes things fall over with a Bus Error. Enjoy. .sub main .local pmc arr1 .local pmc arr2 .local pmc x .local pmc y .local pmc choose .local pmc fail new_pad 0 $P0 = new PerlArray store_lex 0, *paths*, $P0 $P0 = new PerlString $P0 = @ store_lex 0, failsym, $P0 store_lex 0, choose, $P0 store_lex 0, fail, $P0 newsub choose, .Closure, _choose store_lex choose, choose newsub fail, .Closure, _fail store_lex fail, fail arr1 = new PerlArray arr1[0] = 1 arr1[1] = 3 arr1[2] = 5 arr2 = new PerlArray arr2[0] = 1 arr2[1] = 5 arr2[2] = 9 x = choose(arr1) print Chosen print x print from arr1\n y = choose(arr2) print Chosen print y print from arr2\n $I1 = x $I2 = y $I0 = $I1 * $I2 if $I0 == 15 goto success fail = find_lex fail fail() print Shouldn't get here without a failure report\n branch the_end success: print x print * print y print == 15!\n the_end: end .end .sub _choose .param PerlArray choices .local pmc our_try print Choose: $S0 = typeof choices print $S0 print \n new_pad 1 find_lex $P0, fail store_lex 1, old_fail, $P0 store_lex 1, cc, P1 newsub our_try, .Closure, _try store_lex 1, try, our_try $P2 = our_try(choices) .pcc_begin_return .return $P2 .pcc_end_return .end .sub _try .param PerlArray choices print In try\n $S0 = typeof choices print $S0 print \n new_pad 2 clone $P0, choices store_lex 2, choices, $P0 if choices goto have_choices $P1 = find_lex old_fail store_lex fail, $P1 invokecc $P1 have_choices: newsub $P2, .Closure, new_fail store_lex fail, $P2 $P3 = find_lex choices $S0 = typeof $P3 print $S0 print \n shift $P4, $P3 .pcc_begin_return .return $P4 .pcc_end_return new_fail: .local pmc our_try .local pmc our_cc save P1 print In new_fail\n our_cc = find_lex cc our_try = find_lex try $P2 = find_lex choices $S0 = typeof $P2 print $S0 print \n $P3 = our_try($P2) restore P1 unless our_cc == P1 goto do_return print Something's very wrong with continuations!\n do_return: our_cc($P3) .end .sub _fail print Program failed\n .pcc_begin_return .pcc_end_return .end
Re: Fun with nondeterministic searches
[EMAIL PROTECTED] (Leopold Toetsch) writes: Piers Cawley [EMAIL PROTECTED] wrote: Remember how Leo wanted an example of how continuations were used? Great example - I don't understand how it wotks though :) - but I understand, why the PIR code might fail: .sub _choose [ ... ] store_lex 1, cc, P1 You aren't allowed to do that. While P1 is the return continuation passed into C_choose it's not (or may be not) in P1 during the whole function body. That's not guranteed. It's guranteed that returning from the sub will use this continuation, that's all. You can't assume any fixed PASM register for some PIR item. WRT RetContinuation vs Continuation - they are still not the same. I'll try hard to keep the distinction that RetContinuations are only used once (which your program seems not to do). Having that distinction would give us more then 50% speed up in plain function (and method) calls. You can turn off this distinction in src/objects.c:782 with #define DISBALE_RETC_RECYCLING 1 or pass to _choose a real Continuation PMC in P1. (the program still fails, but now differently, I'll have a closer look at it tomorrow) Okay, I fixed it (and slowed it down dramatically) by removing Return Continuations and getting rid of the stack freelist (you can't stick a stack frame on the freelist just because you've popped it, there might be a continuation still looking at it). Honestly, with one item per chunk, immutable stacks, there really is no point in having a special case RetContinuation, you just need to maintain a continuation freelist. I'm going to go through the DOD stuff to see about adding continuation and stack chunk free lists to the interpreter structure. Then when the DOD finds dead stack chunks or continuations during the course of its job, it just shoves 'em onto the appropriate free list and carries on its way. The new_return_continuation_pmc and new_stack_chunk or whatever they're called can pull structures off the appropriate free lists. Also, if stack chunks get garbage collected, which they should be, there's little point in having a doubly linked stack (you can't have 'prev' link back to a free stack frame because the stack is actually a tree).
Re: Windows tinder builds
Dan Sugalski [EMAIL PROTECTED] writes: I finally figured out why the windows machine wasn't showing in the tinderbox, and fixed that. (System dates. D'oh!) We now have (again) a reliable windows machine building parrot for test, both under Cygwin and Visual Studio/.NET (though it builds a native executable there rather than a .NET one) The VS/.NET build works fine, though three of the tests fail for odd reasons. Those look like potential test harness errors. The cygwin build sorta kinda works OK, but the link fails because of a missing _inet_pton. I seem to remember this cropping up in the past and I thought we'd gotten it fixed, but apparently not. Anyway, these are set for hourly builds at half-hour offsets, so if you check in any significant changes it'd be advisable to take a look at the results. For those that don't know, all the tinderbox info is web-accessable at http://tinderbox.perl.org/tinderbox/bdshowbuild.cgi?tree=parrot Hmm... I note that there appear to be no Macintoshes in the tinderbox. I can probably spare some cycles to this; what's the procedure?
Re: Continuations, stacks, and whatnots
Dan Sugalski [EMAIL PROTECTED] writes: At 8:46 AM +0100 3/23/04, Leopold Toetsch wrote: Piers Cawley [EMAIL PROTECTED] wrote: Dan Sugalski [EMAIL PROTECTED] writes: And what control stack? The continuation chain is the control stack, surely? Nope. There's the exception handlers, at the very least. Just add a field to the continuation structure NextExceptionHandler which points to the continuation of the next exception handler in the chain. What about C code that either installs exception handlers or throws exceptions? C code that installs exception handlers is (admittedly) tricky, but C code throwing an exception seems reasonably straightforward. Wrap the C call in a basic exception handler that catches the C exception and rethrows to the current continuation's exception continuation. Or multiple nested exception handlers, Invoke the exception continuation, which restores the appropriate current contination (and associated exception continuation) rethrow the exception by invoking the new current exception continuation, which restores a new current continuation (and associated exception continuation). Rinse. Repeat. or serial exception handlers in a block... Installing an exception handler sets the current exception handler, removing it unsets it, then you install a new one. Any function calls will get appropriate exception continuations depending on the currently set exception handler. And then there's the fun with exception handlers and coroutines. It's a stack, like it or not. So what happens when you invoke a continuation that jumps deep within a functional call chain with a couple of exception handlers? What happens when you do it again? ie: Is the control stack properly garbage collected?
Re: Optimizations for Objects
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Csavetop becomes Cpushtopp if only P-registers are used. Saving only 3 or 5 registers isn't possible yet. We have no opcodes for that. save Pn save Pm Well, these are already used for pushing items onto the user stack. It could be pushtopp 3 # save P16..P18 savetop 4# save 4 regs from all I16 ..., S16, N16, P16 ... P19 and so on. Out of interest, why do we have distinct register and user stacks? [...] ... Presumably, because IMCC knows that cont_ret is a continuation target, it can create the appropriate real_cont_ret and add the appropriate stack manipulation code in there? This would be really cool. The code for creating the continuation and the return must be in sync. When you pass the continuation on into a subroutine and want to return either normally or through the continuation, we need something like: $P0 = newcont dest_label FOR _invoker _invoker($P0) ... dest_label: ... But the function the continuation gets passed to is completely irrelevant. When you make a continuation you want to save exactly the same state as you'd save if you were making a function call at the same point. Say you had code like ... $P0 = Something $P1 = Something else $P2 = Some other thing .newcont $P3, dest_label ... do_return: .pcc_begin_return .pcc_end_return dest_label: print $P0 print $P2 branch do_return Then it'd be cool if IMCC could look ahead to see that when (if) the continuation is invoked, the only registers that get used are $P0 and $P2 and emit something like: ... $P0 = Something $P1 = Something else $P2 = Some other thing save P1 save P2 save $P0 save $P2 $P3 = newcont Continuation, dest_label restore $P2 restore $P0 restore P2 restore P1 ... do_return: .pcc_begin_return .pcc_end_return dest_label: restore $P2 restore $P0 restore P2 restore P1 print $P0 print $P2 branch do_return But I have the feeling I'm thinking IMCC is rather more sophisticated than it is in real life. From the point of view of a programmer, the important thing is that invoking a continuation should return the upper and control registers (but not the argument registers) to the state they were in when the continuation was made. How the continuation is subsequently stored/passed is completely irrelevant to this. Creating correct code from that is a bit ugly, because the continuation is created, before the actual call sequence is generated. So a bit more verbose: .pcc_begin prototyped .arg_newcont dest_label .pcc_call _invoker .pcc_end ... .CONT_TARGET dest_label: That's still complicated but doable. That would need searching the current unit for subroutine calls that have a C.arg_newcont argument, compare the labels and create finally the very same register restore opcode(s) that the function call has. OTOH storing a continuation inside a global can't prepare any code for the continuation return, because nothing about the continuation's usage is known. This is irrelevant. assign $P0, P1 # vtable-set_pmc (N/Y) Assign would be good. I can't really think of an occasion when you'd want to copy anything less than the full context held by the continuation. What about: .sym pmc cont cont = newcont dest ... updatecc cont # assign current P1's context to cont With assign cont, P1 we need another syntax extension to actually get the real P1 register: assign cont, current_P1 or P1 is always restored immediately after function calls (like currently P2). I think, Cassign and restoring P1 immediately would be the most useful combination. Absolutely.
ParrotUnit
Here's version 0.01 of ParrotUnit, my port of the xUnit testing framework to Parrot. It allows you to write your tests for parrot applications using object oriented parrot. Untar it in your parrot directory then do $ parrot t/test.imc 1..3 ok 1 testTemplateMethod ok 2 testTestFailure ok 3 testTestCount and away you go. Right now you have to do a largish amount by hand because Parrot lacks the reflective capabilities needed to do automatic generation of TestSuites etc, and I've yet to come up with a good set of 'assert_*' methods, but what's there is usable (and splendidly undocumented). Enjoy. parrotunit-0.01.tar.gz Description: Binary data
Re: Optimizations for Objects
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: The thing is, 'pushtop' is almost certainly the wrong thing to do. You should only push the registers you care about onto the register stacks. Yes: $ time parrot -j oofib.imc fib(28) = 317811 3.050051s real0m3.077s $ time parrot -j -Oc oofib.imc fib(28) = 317811 2.234049s real0m2.262s Csavetop becomes Cpushtopp if only P-registers are used. Saving only 3 or 5 registers isn't possible yet. We have no opcodes for that. save Pn save Pm ... restore Pm restore Pn Admittedly we don't have opcodes for storing multiple registers at a time, and having them would be a useful optimization... The catch is that, whilst I know which registers *I* care about, I don't know which registers IMCC cares about. So maybe IMCC's 'newcont' should expand to: save 'imcc_magic_register1' save 'imcc_magic_register2' target = newsub .Continuation, dest restore 'imcc_magic_register2' restore 'imcc_magic_register1' Notice how making a continuation looks remarkably like making a function call. The usage of above Continuation would be to pass it on into a subroutine and eventually return through it to an alternate position? Have you looked at the parrotunit code that I (finally) posted? That creates a continuation and calls a method to set it as an object attribute. If you could fix whatever I'm doing wrong there I'd be obscenely grateful btw. Incidentally, the latest rewrite has the continuation created and saved on the object using: savetop P5 = new Continuation set_addr P5, catch0 I0 = 1 I1 = 0 I2 = 0 I3 = 1 I4 = 0 S0 = setFailureHandler callmethodcc restoretop ... finally: thisObject.tearDown() # thisObject is self in a high register... .pcc_begin_return .pcc_end_return catch0: restoretop ... branch finally .end and the continuation is invoked using 'handler(a string) rather than simply invoking it. Catch is, 'finally' gets jumped to twice. Other usages include stuffing the continuation into a global. If yes, then the Continuation should be created inside the call sequence to avoid duplicate register saving and restoring code: res = subroutine(args, NEWCONT) But that's only one side of the business. The code at the return label Cdest) has to restore the same registers too. If the target of the Continuation isn't the function return, it has to look somethin like this: goto around_cont_ret cont_ret_target: restoretop # or whatever was saved around_cont_ret: Oh yes, I'm fine with that. The problem I have at the moment is that I don't know *what* to save and restore. It appears that IMCC uses at least one register in P16-32 to save a copy of P1 so that it'll be caught by a savetop and, in the cases where I was saving individual registers, creating the continuation, and restoring the registers, I was failing to save the current continuation because I didn't know where it was (this is why I want P1 to be invariant over function calls/continuation creation). Presumably, because IMCC knows that cont_ret is a continuation target, it can create the appropriate real_cont_ret and add the appropriate stack manipulation code in there? This would be really cool. If the destination of the continuation is within the current compilation unit (which it probably should be, or things get *very* weird) then, potentially, IMCC knows what registers the continuation target cares about and can automagically save the current .locals as well. Yes. Would it be possible to arrange things so that $P0 = new .Continuation $P0 = P1 # The current RetContinuation makes $P0 into a full continuation equivalent to the RetContinuation? Sure. It depends on what part of the context should be copied into the Continuation: get_addr Idest, P1 set_addr $P0, Idest # assign dest - implemented or assign $P0, P1 # vtable-set_pmc (N/Y) Assign would be good. I can't really think of an occasion when you'd want to copy anything less than the full context held by the continuation. which could do whatever is appropriate. ($P0 = P1 just aliases the two and isn't usable for assignment) D'oh.
Re: Optimizations for Objects
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: You seem to be mixing up different issues with that statement. Using plain Continuation PMCs for returning just from subroutines was dead slow, w or w/o COWed stacks. But when a Continuation is simply a collection of pointers to the tops of the various stacks (and I really do think it should include P1 in that list...) will it really be that slow? I'm surprised. You are missing object creation overhead. P1 and P2 are in the saved P-register frame. And finally: I really don't know, if a Continuation needs just pointers to the stacks (and to which) or (COWed) copies (to which). If a 'single object per stack frame' approah, the continuation only needs pointers to the various stacktops. In fact all that anything will need for dealing with such stacks is a pointer to their current stacktop. *Will please somebody describe all the semantics of Continuation usage.* A Continuation is a closure over the call chain, and the various stacks in the context. Someone proposed in email that, actually, a continuation should close over everything but the parameter registers. Consider the following: savetop $P0 = newcont target store_global theCont, $P0 target: restoretop here: ... When the continuation is invoked using, say, cont(Result1, 2, bibble) the registers and user stacks should look exactly the same as if you had just returned from a normal function call that looked like: a_function_call() here: ie: P1 and P2 would be untouched, as would the high registers, and the various parameter/return registers would be populated with the returned values. Given the way that the stack stuff works, I wonder if there's a case for rejigging the calling conventions so that the control registers (current continuation, self, (methodName?)) are contiguous with the user registers. If we made P15 the current object, P14 the current continuation, and S15 the methodname, then savetop could include them efficiently without IMCC having to do 'set P20 = P1' at the start of every sub that makes a function call. If IMCC were then to always allocate 'user' register in ascending order from 16, presumably it'd be possible to introduce a new op: saverangep 14, 20 saverangei 16, 18 ... Along with associated restorerangep start, count (or should that be restorerangep start, end Thoughts?
Re: typeof ParrotClass
Leopold Toetsch [EMAIL PROTECTED] writes: Should this really print ParrotClass: newclass P0, Foo typeof S0, P0 print S0 print \n find_type I0, Foo new P1, I0 typeof S0, P1 print S0 print \n end ParrotClass Foo Yes.
Re: Optimizations for Objects
Leopold Toetsch [EMAIL PROTECTED] writes:
Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, as I see it there are two big things that we can do to speed
objects up. (Well, besides speeding up the creation of continuation
PMCs, which I am, at the moment, sorely tempted to put in a special
pool for fast allocation)
I though about that already. Returncontinuations created via the *cc
opcode variants are created in the opcode and used exactly once just for
returning from the sub. So I'd do for these a per-interpreter
freelist, where they get put back after invokeing the return
contination.
How hard would it be to stick all continuations onto a 'weak'
continuation stack (not seen by DOD) then, during DOD, mark the freed
continuations (or the live ones). After DOD do the following
# Assume cpool_head = top of stack
#cpool_last = last continuation in stack
#end_of_chain = guard object, is never free
return if cpool_head.isfree
last = cpool_head
this = cpool_head.next
while !this.is_free {
last = this
this = this.next
}
last.next = end_of_chain
cpool_last.next = cpool_head
cpool_head = this
When you come to allocate a continuation, you know that, if the
head of the continuation list isn't free, there are no free
continuations on the list, so you allocate a new one and push it onto
the list.
If the head of the list is free, grab it, mark it as used, rerun the
above algorithm, populate your continuation and continue on your merry
way.
If we use a single value per stack frame approach to the stack we can
recycle stack frames in the same way.
(I know, patches welcome, but my C sucks)
--
Piers
This week's Summary
work goes on, integrating Parrot with
Perl 5, we need to get the embedding interface fixed up so that it plays
well with others.
He was also concerned that we seemed to be reinventing perl's
Configure.SH in a horribly piecemeal fashion and suggested that we
should just dig all the stuff out in one swell foop. Larry pointed
everyone at metaconfig and discussion ensued.
Quite how metaconfig sits with the miniparrot based configuration/build
plan that Dan's talked about was left as an exercise for the interested
reader.
http://tinyurl.com/292d4
Method caching
Work continued on making objects more efficient. The object PMC had a
good deal of fat/indirection removed, and work started on implementing a
method cache. Dan reckoned that the two most useful avenues for
exploration were method caching and thunked vtable lookups.
Zellyn Hunter suggested people take a look at papers on Smalltalk's
dispatch system by Googling for [smalltalk cache].
Mitchell N Charity suggested a couple of possible optimizations (and
benchmarks to see if they're worth trying).
There was some discussion of the costs of creating return continuations.
(My personal view is that the current continuation and stacks
implementation isn't the Right Thing, but I don't have the C skills to
implement what I perceive to be the Right Thing. Which sucks.)
Leo reckons that, with a method cache and continuation recycling, he's
seeing a 300% improvement in speed on the object oriented Fibonacci
benchmark.
http://tinyurl.com/2ypmc
http://tinyurl.com/2uvzd
ICU incorporation
Jeff Clites gave everyone a heads up about the work he's doing on a
patch to incorporate the use of ICU (the Unicode library Parrot will be
using) and some changes to our internal representation of strings.
Apparently the changes give us a simpler and faster internal
representation, which can't be bad.
http://tinyurl.com/2gc3t
Continuation usage
Jens Rieks and Piers Cawley both had problems with continuations. Leo
Tötsch tried explain what they were doing wrong. There seemed to be a
fair amount of talking past each other going on (at least, that's how it
felt from my point of view) but I think communication has been
established now. Hopefully this will lead to a better set of tests for
continuation usage and a better understanding of what they're for and
how to use them.
http://tinyurl.com/yv4ag
http://tinyurl.com/2ra6h
Optimization in context
Mitchell Charity argued that we should think carefully before doing too
much more optimization of Parrot until we've got stuff working
correctly. Leo agreed, up to a point, but pointed out that optimizing
for speed is lot of fun. Brent Royal-Gordon thought that it was a
balancing act, some things are painfully slow and need optimizing, at
other times, things are painfully none existent and need to be
implemented. Objects were both of those things for a while.
Piers Cawley said that, for all that objects were slow (getting faster),
he thought they were rather lovely.
http://tinyurl.com/38tly
Meanwhile, in perl6-language
Hash subscriptor
At the back end of the previous week, Larry introduced the idea of
subscripting hashes with %hash«baz» when you mean %hash{'baz'}. This
surprised John Williams (and others I'm sure, it certainly surprised me,
but it's one of those What? Oh... that makes a lot of sense type
surprises.) Larry explained his thinking on the issue. Apparently it
arose because :foo('bar') was too ugly to live, but too useful to die,
so :foo«bar» was invented, and once you have that, it is but a short
step to %foo«bar». (If you've not read Exegesis 7, you probably don't
know that :foo«bar» is equivalent to foo = 'bar', but you do now.)
John wasn't convinced though. It remains to be seen if he's convinced
Larry.
Larry: unfortunately it's an unavoidable part of my job description to
decide how people should be surprised.
http://tinyurl.com/3yju9
Mutating methods
Oh lord... I'm really not following this particular thread. The mutating
methods thread branched out in different directions that made my head
hurt. I *think* we're still getting
$aString.lc; # None mutating, returns a new lower case string
$aString.=lc; # Mutating, makes $aString lower case
I'm going to bottle out of summarizing the rest of the thread. Hopefully
subthread perpetrators will be kind to an ageing Summarizer and change
subject lines to reflect the content of a given subthread. Ta.
Some questions about operators
Joe Gottman has been reading Synopsis 3 and had a bunch of questions.
Much of the ensuing discussion covered the use of the 'broken bar' glyph
as an infix form of the zip operator. Which I didn't quite realise
Re: Using Ruby Objects with Parrot
Nick Ing-Simmons [EMAIL PROTECTED] writes: Mark Sparshatt [EMAIL PROTECTED] writes: I'm not 100% certain about the details but I think this is how it works. In languages like C++ objects and classes are completely seperate. classes form an inheritance heirachy and objects are instances of a particular class. However in some languages (I think that Smalltalk was the first) there's the idea that everything is an object, including classes. So while an object is an instance of a class, that class is an instance of another class, which is called the metaclass. I don't there's anything special about these classes other than the fact that their instances are also classes. Thinking about it I think you may have the relationship between ParrotObject and ParrotClass the wrong way around. Since a class is an object but and object isn't a class it would be better for ParrotClass to inherit from ParrotObject, rather than the other way round. In Ruby when you create a class Foo, the Ruby interpreter automatically creates a class Foo' and sets the klass attribute of Foo to point to Foo'. This is important since class methods of Foo are actually instance methods of Foo'. Which means that method dispatch is the same whether you are calling an instance of class method. So in perl5-ese when you call Foo-method you are actually calling sub Foo::method which is in some sense a method of the %Foo:: stash object. So what you suggest is as if perl5 compiled Foo-method into (\%Foo::)-method and the %Foo:: 'stash' was blessed... Personally, I've always wished that Perl5 *had* done that. I've toyed with the idea of blessing Stashes, but never got around to actually implementing anything.
Re: Continuations, stacks, and whatnots
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: ... If we go with a one frame stack chunk then we don't have to bother with COW-ing *anything* with the stack. BTW: which stacks: Register frames of course. What about Pad, User, and Control? I hope he means All of 'em. And what control stack? The continuation chain is the control stack, surely?
Re: Continuations, stacks, and whatnots
Dan Sugalski [EMAIL PROTECTED] writes: At 12:59 AM + 3/23/04, Piers Cawley wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: ... If we go with a one frame stack chunk then we don't have to bother with COW-ing *anything* with the stack. BTW: which stacks: Register frames of course. What about Pad, User, and Control? I hope he means All of 'em. And what control stack? The continuation chain is the control stack, surely? Nope. There's the exception handlers, at the very least. Just add a field to the continuation structure NextExceptionHandler which points to the continuation of the next exception handler in the chain. To throw an exception you invoke that exception. If that exception handler needs to rethrow the exception, its P1 will contain the appropriate continuation. Possibly some lexical pad stuff. (Though of that I'm less sure) I've always wondered why lexical pads have their own stack. I'd hang it off the Sub object and, when the sub's invoked, shove the current pad into a control register, which then gets closed over by any continuations that get made. Invoking a continuation restores the pad register and away you go.
Continuations (again)
So, I'm trying to get my head 'round parrot's continuations. It's my understanding that, at creation time, a Continuation closes over the current user stacks, control stack and lexical pad (and possibly some other stuff but those'll do for now). So, it seems to me that the following code should print Howdy, world. .sub main $P0 = new PerlUndef $P0 = Howdy, world\n save $P0 $P1 = newcont after #$P1 = new .Continuation #set_addr $P1, after invoker($P1) sub_end: .pcc_begin_return .pcc_end_return after: restore $P2 print $P2 branch sub_end .end .sub invoker .param pmc a_cont invoke a_cont .pcc_begin_return .pcc_end_return .end Except, what actually happens is: Parrot VM: PANIC: Illegal rethrow! C file src/exceptions.c, line 356 Parrot file (unknown file), line 0 Which isn't quite what I had in mind. Bizarrely, if I do: $ parrot -o howdy.pasm howdy.imc $ parrot howdy.pasm Howdy, world $ everything's fine. Weird hunh?
Re: Continuations (again)
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: So, I'm trying to get my head 'round parrot's continuations. It's my understanding that, at creation time, a Continuation closes over the current user stacks, control stack and lexical pad (and possibly some other stuff but those'll do for now). Yes register stacks. Which is one problem of your code. The calling sequence has a savetop inside, which isn't in the Continuations context. But why do I need the savetop? I only care about the I already posted an working example. Here is another one (comments indicate problems with your code: .sub main $P0 = new PerlUndef $P0 = Howdy, world\n save $P0 # create continuation inside, so that it has this in context savetop $P1 = newcont after P5 = $P1 P0 = find_global _invoker invokecc after: restoretop restore $P2 print $P2 end # end *is* needed in main .end .sub _invoker #^^ global labels have an underscore .param pmc a_cont invoke a_cont .end Weird hunh? As long as no one really can tell the semantics of Continuations, they have to be hand-crafted like above. So why does the generated pasm work where the PIR doesn't? I can see why saving P0-2 would be a good idea, but after doesn't need any of the other registers.
Re: Optimizations for Objects
Matt Fowles [EMAIL PROTECTED] writes: All~ Piers Cawley wrote: I argue that we have the problems we do (incorrect behaviour of continuations, horrible allocation performance) because we chose the wrong optimization in the first place. The stack optimizations that are in place make sense when you don't have continuations, but once you do, the cost of allocating a continuation and maintaining all that COW complexity becomes prohibitive. I strongly advocate rejigging the stacks so that one stack frame = 1 stacked thing + 1 link to the next thing in the chain. No need for COW, no need for memcpy when allocating continuations, no worrying complexity to deal with while you're trying to get the behaviour right. Oh, an no need for RetContinuations either. I feel like Piers has asked this several times and never gotten an answer about why it is (or is not) a good idea. I agree with him that it is a good idea, but I am far from an authoritative source. Also, Piers didn't you implement this once already? If could you update it to the current system without too much trouble? It would be nice to have numbers on this approach. Nope, never implemented it. I have the C skills of a teeny tiny kitten.
Re: Optimizations for Objects
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: ... I strongly advocate rejigging the stacks so that one stack frame = 1 stacked thing + 1 link to the next thing in the chain. Let's do things in correct order. First was method cache. 2nd the debatable return continuation recycling. Both accummulated, sum up to 300% speedup. Next is - that's true - stack code or better register preservation costs. Please note that the current stack code is in, to make it working again. It was broken a long time. Now its by far less broken. All improvements are welcome. ... No need for COW, no need for memcpy when allocating continuations, no worrying complexity to deal with while you're trying to get the behaviour right. Implementations of better schemes are much appreciated. Oh, an no need for RetContinuations either. You seem to be mixing up different issues with that statement. Using plain Continuation PMCs for returning just from subroutines was dead slow, w or w/o COWed stacks. But when a Continuation is simply a collection of pointers to the tops of the various stacks (and I really do think it should include P1 in that list...) will it really be that slow? I'm surprised.
Re: Continuations (again)
Piers Cawley [EMAIL PROTECTED] writes: Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: So, I'm trying to get my head 'round parrot's continuations. It's my understanding that, at creation time, a Continuation closes over the current user stacks, control stack and lexical pad (and possibly some other stuff but those'll do for now). Yes register stacks. Which is one problem of your code. The calling sequence has a savetop inside, which isn't in the Continuations context. But why do I need the savetop? I only care about the Oops... what happened to that sentence? Anyhoo, I looked again at the generated .pasm and noticed that P1 was getting copied up to P20 so, if you don't do the savetop you're never going to get the current continuation back. (I know, I'm telling you something you already know). It seems to me that there's a good case for saying that P1 should be closed over when a continuation is made and restored when it's invoked. Not having to manage P1 explicitly until and unless you want to promote it to a full continuation should help enormously when you're wanting to write code that does (amongst other things) tail call optimization because you know that, unless you've fiddled with it yourself, P1 is always the current continuation. (Right now you have to restore P1 from whichever hidden PMC register IMCC has hidden it in, set up the various call registers by hand, stick the sub in the right place and call it with invoke not invokecc. Since you don't actually know *where* IMCC has shoved the continuation this is a little tricky. You end up having to duplicate the work.) Dan? Could you mandate this? Please? Preserving self and the current function object could also be rather handy...
Re: Optimization in context
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] writes: Other times, we add lots of new features, and then stop to test them and find they're incredibly slow. (That's objects right now.) In objects' defence, I'd just like to say that they are rather lovely.
Re: Optimizations for Objects
Luke Palmer [EMAIL PROTECTED] writes: Piers Cawley writes: You seem to be mixing up different issues with that statement. Using plain Continuation PMCs for returning just from subroutines was dead slow, w or w/o COWed stacks. But when a Continuation is simply a collection of pointers to the tops of the various stacks (and I really do think it should include P1 in that list...) will it really be that slow? I'm surprised. I implemented this in the register stacks, but I didn't spend any time on optimization (and who knows, I may have even been marking the stacks COW unnecessarily). Continuation creation, call, and return had great performance. But the problem was that pushtop, etc. were much slower than with the current scheme. The thing is, 'pushtop' is almost certainly the wrong thing to do. You should only push the registers you care about onto the register stacks. I still find it odd that pushing 16 register onto the stack is quicker than pushing 3 (for appropriate values of 3) The catch is that, whilst I know which registers *I* care about, I don't know which registers IMCC cares about. So maybe IMCC's 'newcont' should expand to: save 'imcc_magic_register1' save 'imcc_magic_register2' target = newsub .Continuation, dest restore 'imcc_magic_register2' restore 'imcc_magic_register1' Notice how making a continuation looks remarkably like making a function call. If the destination of the continuation is within the current compilation unit (which it probably should be, or things get *very* weird) then, potentially, IMCC knows what registers the continuation target cares about and can automagically save the current .locals as well. I would love to see RetContinuation leave, honestly. One of the greatest things about CPS is that you can grab anybody's continuation that they passed you and store it somewhere. RetContinuation is just a computed goto. Would it be possible to arrange things so that $P0 = new .Continuation $P0 = P1 # The current RetContinuation makes $P0 into a full continuation equivalent to the RetContinuation?
Re: Optimizations for Objects
Leopold Toetsch [EMAIL PROTECTED] writes:
Larry Wall [EMAIL PROTECTED] wrote:
On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
: I'd like to have, if possible a clear indication: that's a plain
: function or method call and this is not. I think the possible speedup is
: worth the effort.
I have no problem with plain being the default. I suppose you could
declare it explicitly if you like:
sub foo () is plain {...}
Then obviously the other kind would be:
sub bar () is peanut {...}
There is of course no need to declare the default, which will be very
likely beyond 99%. I won't discuss P6 syntax here, which could lead to
sub bar() will reuse_P1 { ... }
Piers' statement was related to solving the halting problem, which isn't
really positive. I don't throw or catch pies, but CPS returns are
currently the major performance loss Parrto has.
I argue that we have the problems we do (incorrect behaviour of
continuations, horrible allocation performance) because we chose the
wrong optimization in the first place. The stack optimizations that are
in place make sense when you don't have continuations, but once you do,
the cost of allocating a continuation and maintaining all that COW
complexity becomes prohibitive. I strongly advocate rejigging the
stacks so that one stack frame = 1 stacked thing + 1 link to the next
thing in the chain. No need for COW, no need for memcpy when allocating
continuations, no worrying complexity to deal with while you're trying
to get the behaviour right. Oh, an no need for RetContinuations either.
Re: Optimizations for Objects
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote: Which brings up again my warnocked question: How can return continuations get reused? Works like this. (No pasm, but it should be obvious) Ok. First (and that applies to Jens example too), I'd like to outline continuation vs return continuation and its usage: 1) First there was only a Continuation PMC. Performance with CPS sucked. So I did invent a RetContinuation PMC Performance sucked less. The difference between these two is: the former has COW copied stacks inside its context, the latter has only pointers of the stacks in its context. 2) A return continuation is automatically created by invokecc callmethodcc It's totally hidden when using PIR function or method call syntax _func(a, b) obj.meth(args) These internally create above opcodes and create a new return continuation on each sub or method invocation 3) Returning from the sub or method in PIR syntax again totally hides the return continuation .pcc_begin_return .return result .pcc_end_return .end or just .sub _foo .end# automatic return sequence inserted. 4) From PIR level there is no official way to even reference this return continuation - its invisible. 5) *But* If a continuation's taken from within a sub somewhere, return continuations may (probably will) be used multiple times, once for the original return then once for each time the continuation is invoked. 6) Yes, that's true. So the questios is: Can we invent some HLL PIR syntax that clearly indicates: this subroutine will return multiple times through the same return continuation. We have already a similar construct for Coroutines: .pcc_begin_yield .result # optional .pcc_end_yield This is invokeing the coroutine and returns to the caller. What's the usage of Continuations from HLLs point of view? Can we get some hints, what is intended? I'd like to have, if possible a clear indication: that's a plain function or method call and this is not. I think the possible speedup is worth the effort. I think that requires solving the halting problem.
Re: Continuation usage
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Jens Rieks [EMAIL PROTECTED] writes: Hi, does the attached test use the Continuation in a correct way? The test failes, what am I doing wrong? Without running it I'm guessing that it prints out something like 456=789 456=456 123=123 Why would it print 3 lines? Actually, it doesn't, I was going mad and mixing it up with the problem I've been having with ParrotUnit, which does bad things with returning...
Something rotten with the state of continuations...
I've been trying to implement a Parrot port of xUnit so we can write tests natively in parrot and things were going reasonably well until I reached the point where I needed to do exception handling. Exception handling hurt my head, badly, so eventually I gave up and used a continuation instead. Here's the basic 'run' and 'exception failure' parts of my code (The current full suite is in the tar file attached): .sub run method .param pmc testResult .local Sub handler .local Sub exceptRet .local pmc name .local string nameString name = self.name() self.setResult(testResult) save nameString handler = new Continuation set_addr handler, catch0 self.setFailureHandler(handler) self.setUp() self.name() testResult.pass(nameString) finally: self.tearDown() .pcc_begin_return .pcc_end_return catch0: P17 = self.name() S16 = P17 P16 = P2.testResult() P16.fail(S16) branch finally .end .sub assertion_failed method .param string rawMsg .local pmc handler handler = self.failureHandler() # invoke handler handler() .end Now, depending on whether I use Chandler() or Chandler, teardown gets run 3 (handler()) or two (invoke) times. If I create the handler continuation using Chandler = newcont break0 then it makes it to branch0, but there are problems with self, the first method call works fine, but after that things go haywire and self appears to get trashed so method lookups fail after the first one. Very frustrating. BTW, you can make Leo's test program go into an infinite loop simply by replacing the n conti = newcont _end with new conti, .Continuation set_addr conti, _end which is weird because I *thought* they were supposed to do equivalent things.
Oops, here's the full parrotunit
I knew I forgot something in my last post... If you unpack this in your parrot directory you'll get library/parrotunit.imc library/TestCase.imc library/TestResult.imc library/WasRun.imc t/test.imc Go to the parrot directory and, do ./parrot t/test.imc and the tests will run. Annoyingly, everything works perfectly if none of the tests fail...
Re: Oops, here's the full parrotunit
parrotunit.tar.gz Description: Binary data
Re: Method caches
Larry Wall [EMAIL PROTECTED] writes: On Wed, Mar 17, 2004 at 12:41:20PM -0500, Dan Sugalski wrote: : Currently I'm figuring on just nuking the whole cache in any of these : cases. Later on we can consider doing Clever Things, if it seems : worthwhile. That's what Perl 5 does, FWIW. But you're caching scheme seems way too complicated to me. In Perl 5, you cache the method simply by making it look like it's a member of the current class. There's very little extra mechanism. You just have to know which methods are the fake ones you can blow away. And this is why Perl 5 can't work out SUPER:: type stuff at runtime. It's possible through cleverness to find out where you were found the *first* time you're called, but the information isn't retained in the cache. Which is a complete and utter PITA.
Re: Continuation usage
Jens Rieks [EMAIL PROTECTED] writes: Hi, does the attached test use the Continuation in a correct way? The test failes, what am I doing wrong? Without running it I'm guessing that it prints out something like 456=789 456=456 123=123 And on running it, I see that I'm right. Remember that invoking a continuation does nothing to the existing register state (which is as it should be). So why does it work like this? Letting IMCC handle calling _func saves all the registers and sets P1 to a RetContinuation that points to _func's return point (which is sort of inside the _func() line because of the stuff IMCC does on a function return). _func then sets P16-18 to 4-6 respectively and you make the continuation. Calling _do_something saves all the registers and sets P1 to (essentially) _end _do_something sets P16-18 to 7-9 then jumps through the continuation back to _end. Which prints out '456=789' because P16-18 haven't been restored Then it returns. Returning invokes P1, which is currently set to point to _end. However, returning using .pcc_*_return also restores the registers, which means P16-18 now contain 4-6, so it prints out 456=456 and returns through P1, which now boints back to the original place that _func was called from. Easy. One part of your problem (The state of P16-18) is, therefore, a bug in your program. The other part seems to be a bug in the current implementation of Continuation. A new Continuation should grab the current P1 continuation. If you later invoke that Continuation, it should make the jump and reset P1. Until that's done, all we have is a heavyweight goto.
Re: Methods and IMCC
Dan Sugalski [EMAIL PROTECTED] writes: At 9:49 AM +0100 3/12/04, Leopold Toetsch wrote: Dan Sugalski wrote: Calling a method: object.variable(pararms) Do we need the more explicit pcc_call syntax too: .pcc_begin .arg x .meth_call PObj, (meth | PMeth ) [, PReturnContinuation ] .result r .pcc_end Sure. Or we could make it: .pcc_begin .arg x .object y .meth_call foo .result r .pcc_end to make things simpler. So long as you can also do .meth_call foo, PReturnContinuation
Re: Classes and metaclasses
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: The one question I have is whether we need to have a call class method operation that, when you invoke it, looks up the class of the object and redispatches to it, or whether class methods are just methods called on class objects. The terms are misleading a bit here. - a ParrotClass isa delegate PMC - a ParrotObject isa ParrotClass ^^ That definitely seems to be the wrong way 'round. - a HLL class isa Parrotclass and a low-level PMC object - a HLL object isa all of above
Re: Classes and metaclasses
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: The one question I have is whether we need to have a call class method operation that, when you invoke it, looks up the class of the object and redispatches to it, or whether class methods are just methods called on class objects. The terms are misleading a bit here. - a ParrotClass isa delegate PMC - a ParrotObject isa ParrotClass ^^ That definitely seems to be the wrong way 'round. Why? A ParrotClass is responsible for the method dispatch. The ParrotObject inherits that behavior. But logically, a Class is an Object, and an object is an *instance* of a class. Surely a class should be responsible for storing and finding method, but some other thing, call it a Dispatcher object (in Smalltalk it's the Interpreter, but we've got one of those already), is responsible for the actual dispatch. By making the dispatcher drive the dispatch sequence you can do nice things like decoupling the method cache from the class itself, just have the dispatcher maintain its own cache. Then when something changes that might invalidate the cache you just tell the dispatcher to flush its cache and carry on; no need to go finding every affected class and having them flush their caches. Having a dispatcher object helps with multimethod dispatch too of course (and where are you going to stick your multimethod lookup cache if you *don't* have a dispatcher object). Of course, if you have OO languages that have weird dispatch rules, you might need to have multiple dispatchers hanging around but (I'd argue) you're still better attaching them to classes using composition rather than inheritance.
Re: LANGUAGES.STATUS
Mitchell N Charity [EMAIL PROTECTED] writes: (1) LANGUAGES.STATUS is out of date. I found (on linux x86 [1]): These languages failed to build: BASIC/interpreter jako miniperl tcl And these languages were quite broken (bad make test failures): BASIC/compiler [2] m4 ruby scheme LANGUAGES.STATUS says they all work. If my result is typical, adding a S: Not working as of 0.0.14 release. line to each of these entries seems appropriate. (2) Also, these languages' directories could really use README's: python plot README's saying just what their LANGUAGES.STATUS entries say (elsewhere and broken and abandoned, respectively). Ditch plot, it was a quick and dirty attempt at a scheme interpreter based on closures at OSCON last year that failed dismally. I keep meaning to do something properly now that we have objects, but it won't be in the parrot tree 'til it's working.
Re: Release doc tasks
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: Nah. Modern filesystems understand that A and a are the same letter. It's those old antique filesystems that don't understand that... :-P yeP dAn, yOu ArE rIghT. Still the same letters. Just a strange choice of glyphs.
Re: Some minor decisions and timetables
Uri Guttman [EMAIL PROTECTED] writes: DS == Dan Sugalski [EMAIL PROTECTED] writes: DS At 4:28 PM +0100 2/4/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Okay, here's a quick scoop and status. *) I'd like to shoot for a Feb 14th release. Names wanted. (I'm partial to the bleeding heart release, but not that partial) I had planned towards Feb 29th. A nice dated too this year. DS Works for me. then how about calling it the bleaping insert avian release? :) The Leaping Kakapo release?
Re: References to hash elements?
Simon Cozens [EMAIL PROTECTED] writes: Arthur Bergman: I am wondering how the references to hash elements are planned to be done? The call to set_ must somehow be delayed until the time is right. I would have thought that a hash element would itself be a PMC rather than an immediate value, so a reference to that should be treated just like any other reference to a PMC. I believe the correct name for this is 'Pair' isn't it?
Re: Continuations don't close over register stacks
Melvin Smith [EMAIL PROTECTED] writes: At 06:37 PM 1/7/2004 -0700, Luke Palmer wrote: Leopold Toetsch writes: Jeff Clites [EMAIL PROTECTED] wrote: On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote: That part is already answered: create a buffer_like structure. *But* again register backing stacks are *not* in the interpreter context. I don't understand what you are getting at. They are not physically part of Parrot_Interp.ctx, but it holds pointers to them, right? No, they were in the context but aren't any more. ... So, they need to be copied when the context is being duplicated. Is that your point, or are you trying to say that they are not _logically_ part of the context, or are not supposed to be? Exactly the latter: That was AFAIK a design decision, when Dan did introduce CPS. At this time register backing stacks went out of the continuation or whatelse context - IIRC did Dan commit that to CVS himself. In which case I feel obliged to contest that decision. The register backing stacks are as much a part of the current state as the program counter is. I tend to agree, but maybe Dan can explain. I looked back at the CVS history and when I put continuations in, I did originally have register stacks in the Parrot_Context (although they weren't yet garbage collected). Dan since reverted that and put them back to the top level interpreter object. I also agree. Continuations that don't save the register stacks are about as much use as a chocolate teapot. Maybe it was supposed to be a temporary reversion until GC got sorted.
Re: This week's summary
Lars Balker Rasmussen [EMAIL PROTECTED] writes: The Perl 6 Summarizer [EMAIL PROTECTED] writes: Me? I think Perl 6's design 'in the large' will be pretty much done once Apocalypse 12 and its corresponding Exegesis are finished. Of course, the devil is in the details, but I don't doubt that the hoped for existence of a working Perl6::Rules by the end of April is going to provide us with a great deal of the leverage we need to get a working Perl 6 alpha ready for OSCON with something rather more solid ready by the end of the year. Parrot continues to amaze and delight with its progress; Dan tells me that he's about ready to roll out a large parrot based application for his employers, so it's approaching the point where people's salaries will depend on Parrot. I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? Optimistic. Parrot being used for other languages too is a good thing. We're not going to see a full Perl 6 inside a year 'cos the design won't be finished (well, not at the detailed level it needs to be for a full implementation) and Ponie probably won't be finished because of the complexities of getting the backwards compatilibility with XS that's Ponie's raison d'etre. But there are other languages out there that don't have such stringent requirements. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
Melvin Smith [EMAIL PROTECTED] writes: At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: people's salaries will depend on Parrot. I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? Knowing Piers, I would guess: optimistic. :) Have we met? You're right though. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
Melvin Smith [EMAIL PROTECTED] writes: At 09:30 PM 1/5/2004 +, Piers Cawley wrote: Melvin Smith [EMAIL PROTECTED] writes: At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: people's salaries will depend on Parrot. I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? Knowing Piers, I would guess: optimistic. :) Have we met? You're right though. Unless you count our chats on IRC, no. I can deduce that much from IRC and summaries. We do read them, you know. :) Thank heavens for that. I thought people printed them out and used them to roll cigarettes with. -- Piers
Re: PMC registry
Sam Vilain [EMAIL PROTECTED] writes: Presumably this all means that Parrot will be able to due ruby-esque iteration over all objects (if I may use the term PMC to refer to an object ;-)) that have been created? ITYM Smalltalkesque. HTH, HAND. -- Sam Vilain, [EMAIL PROTECTED] The meek shall inherit the earth, but not its mineral rights. J PAUL GETTY
Re: This week's summary
Michael Joyce [EMAIL PROTECTED] writes: Thank you for a lovely Christmas Present. Any time.
Re: [perl #24683] [PATCH] P6C update concat and bitwise operators
Allison Randal [EMAIL PROTECTED] writes: Piers wrote: p6d? The perl6-documentation list. Started around Nov. 2002, it had about 3 months of heavy traffic and not much since. But, we did get a good plan for the direction of p6 testing out of it. I find that the best way to remember the answer to a question is to ask the 'net. Usually, about 10 seconds after the mail leaves my server I remember what the answer was.
Re: [perl #24683] [PATCH] P6C update concat and bitwise operators
Allison Randal [EMAIL PROTECTED] writes: Leo wrote: I've added two test files, bitwise.t and concat.t, which go in t/op/ (the op/ directory doesn't exist yet) Missing? The directory needs to be added. We're gradually moving our way toward the test hierarchy planned on p6d: p6d?
Re: This week's summary
The Perl 6 Summarizer [EMAIL PROTECTED] writes: Vocabulary If you're even vaguely interested in the workings of Perl 6's object system, you need to read the referenced post. Luke Palmer, worrying about people using Object related vocabulary in subtly inconsistent ways, posted a glossary explaining how OO terminology is used in a Perl 6 context. Casey West wrapped it up in a POD, which will, I hope, end up on dev.perl.org soon. Of course, there were a few corrections for subtleties, a few rethinks of the design so far, and general gratitude for at least having a baseline document that people could refer to. http://groups.google.com/[EMAIL PROTECTED] This should, of course, read: http://groups.google.com/[EMAIL PROTECTED] Apologies for the confusion. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
Luke Palmer [EMAIL PROTECTED] writes: Piers Cawley writes: The Perl 6 Summarizer [EMAIL PROTECTED] writes: http://groups.google.com/[EMAIL PROTECTED] This should, of course, read: http://groups.google.com/[EMAIL PROTECTED] Or even: http://groups.google.com/[EMAIL PROTECTED] We have a winner!
Re: saveall/retoreall in imc?
Thies C. Arntzen [EMAIL PROTECTED] writes: hiya, still working onm this php-compiler;-) thanx for all the replies on my last issue.. next question: calling conventions. in the calling_convertion.pod you say that the callee should ^^ Caller, surely? At least, if you're using the parrot calling conventions (and you should be). do a saveall, restoreall. shouldn't imcc be smart about those things and save all registers that are used in a function?
Re: Proposal: parrot-compilers list
Melvin Smith [EMAIL PROTECTED] writes: In the past couple of years we've seen several sub-projects pop-up and subsequently fizzle out (maybe due to Parrot slow progress or maybe due to lack of critical mass). I propose creating 'parrot-compilers' as a general purpose list for any and all language development (until an appropriate time where said language outgrows the list maybe...). This might allow many small projects to feed off the collective energy of other small projects. I also volunteer to maintain and mail the FAQ out monthly, which is something I always liked about comp.compilers. The list would center around IMCC and higher up the compiler stack with the addition of various other topics that might not be specific to Parrot. Also it would, by namesake, be language neutral and might bring more people in from non-Perl camps as well as give some of us compiler enthusiasts a place to have our long drawn out spam^H^H^H^Hdiscussions without drowning the mailboxes of the general VM population. As long as it still gets delivered to perl6-all and gets traffic, I'll summarize it happily. I can usually understand the compiler writer's issues with Parrot where the full internals stuff leaves my head spinning so I'd be sorry if you all went off somewhere and I wasn't writing summaries.
This week's summary
The Perl 6 Summary of the week ending 20031109 Traditionally this paragraph concerns itself with a few words on what I've been up to before finally settling down to get the summary written. But despite the fact that it's nearly four o'clock, it's been one of those days where I seem to have done almost as much as Leon Brocard generally does to warrant a mention each week. So, here's what's been happening in perl6-internals to make up for the lack of guff about breadmaking or whatever. (If you're interested, the raisin borodinsky I mentioned last week was an unmitigated disaster. The focaccia was fabulous though). New glossary entries Gregor N. Purdy has added a few entries to the Parrot glossary, so if you've been bursting to know what PIR, IMCC and other Parrot specific clusters of capitals stand for, check out docs/glossary.pod in the parrot distribution. http://xrl.us/3pv String Encodings hurt my head! Peter Gibbs is attempting to implement the DBCS encoding (whatever that is) and has discovered that he can't implement skip_backward for it because of the mixture of 1-byte and 2-byte characters. He offered seven suggestions for the right thing to do at this impasse. Michael Scott didn't have any suggestions about the Right Thing, but he did point to a page on his very lovely Parrot Wiki which discussed most things Unicode for parrot, and made a plea for Dan (or whoever) to produce a Strings PDD. http://xrl.us/3pw http://xrl.us/3px - Michael's WikiWord Perl 6 patches Allison Randal posted a couple of patches to the current (very) mini Perl 6 that comes with Parrot (in languages/perl6. A little later in the week, Joseph F. Ryan contributed a Perl 6 patch. It's good to see this receiving attention again. http://xrl.us/3py Documentation Nick Kostirya wondered why docs/parrot_assembly.pod appeared to be simply an old version of docs/pdds/pdd06_pasm.pod. He also worried that docs/ops/ appeared to be empty in the 0.0.13 release of Parrot. Dan noted that both of the parrot assembly docs were wrong, and that what would probably happen would be that the PDD would be updated and docs/parrot_assembly.pod would be retired. Jürgen Bömmels said that the empty docs/ops was because during the Great Move, the Makefile that generated those POD files didn't get updated to cope with the new location of the .ops files. Nick wondered which other POD files might be going away so he'd not have to go through the process of translating obsolete docs into Russian. http://xrl.us/3pz http://www.parrotcode.ks.ua/docs -- Why can't I type in Cyrillic? From the Interesting, but is it useful? department Melvin Smith has been playing with an uncommitted version of invoke which allows you to invoke a function by name not address. He outlined the ideas behind it (and the workaround to make it play nice with the GC system), but wondered if it was actually of any use. Dan and Leo both agreed that it wasn't because of issues with threading and the JIT. http://xrl.us/3p2 Freeze/thaw data format and PBC Leo Tötsch is working on the data serialization/deserialization (aka Freeze/Thaw) system discussed over the last few weeks. He wondered if there were any plans for the frozen image data format. Leo's plan is to use PBC constant format (with possible extensions) so things integrate neatly into bytecode. Dan had a bunch of comments, but the PBC based format idea seemed to be well received, with the caveat that it should be a 'dense' format. http://xrl.us/3p3 Opening files on other layers Jürgen Bömmels asked for comments on a patch for opening files on different layers which had a few issues that he felt needed clarifying. He and Melvin Smith spent some time discussing things. Apologies for not doing a better job in summarizing this thread, but I'm hamstrung by not quite knowing what 'layer' means in this context. http://xrl.us/3p4 Parrot Has PHP Okay, so the subject line's not quite true (yet), but who could resist the recursive acronyminess of it? Anyhow: Thies C. Arntzen and Sterling Hughes, core PHP hackers, popped up to discuss the work they're doing on porting PHP to Parrot. Specifically, they've hit a performance snag where PHP's typeless nature meant using a PMC where they would rather be using a native type for speed. Thies proposed a new datatype to get 'round the issue. The general response was Hey! Fabulous! Someone's making a serious effort to port a real language to Parrot! But that new type suggestion is just reinventing the PMC. Oh, and if you could change your generated code slightly you'd get much faster execution. It's definitely fabulous though. http://xrl.us/3p5
Re: This week's summary
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Parrot Calling Convention Confusion ... -- I thought they were exactly the same as an unprototyped call, but you invoke the return continuation (P1) instead of P0, the other registers are set up exactly as if you were making an unprototyped function call. Unfortunately the call and return conventions are *not* symmetric - yet. S. Fdocs/ppds/pdd03_calling_conventions.pod. Well, yeah, but Dan's said they will be. [ Gives Dan a Paddingtonesque Hard Stare ]
Re: Suggestion for Perl6 summaries
Ron Grunwald [EMAIL PROTECTED] writes: Hello Piers, I really enjoy reading your Perl6 summaries, and that you send them out so reliably every week. I was just wondering whether it would be worthwhile adding a paragraph to the beginning or end of the summary, stating what the various acronyms, such as IMCC, PMC, or PIR, stand for and perhaps give a one-line explanation of each (if that's possible) ? Good idea. I *would* just provide a pointer to docs/glossary.pod, but it looks like it's missing a definition of (at least) PIR. If anyone more competent than myself were to fill in the appropriate definitions I would, of course, be enormously grateful.
