Re: [PATCH] Continuations now close over register stacks
Luke Palmer [EMAIL PROTECTED] wrote: This patch re-implements the register backing stacks as PObjs (so they can be garbage-collected), honors their COW flags, and adds them to the interpreter context (where they should be, honest!). As a healthy side-effect, it encapsulates their behavior nicely into register.c, when before their guts were splattered all over the source. Applied, thanks. Some remarks WRT the patch: 1) struct RegStack doesn't need the chunk_size data member top-data.buflen has the exact size So ctx.type_reg_stack could be a general StackChunkBuf 2) pad, control and user stacks could very likely use the same stack infrastructure. COW copying of these is still b0rken but needed as well. 3) The LEA allocators implementation does only handle COW copying of string memory. This should be fixed, that is, allocate one sizeof(int) + the requested memory and consider the memory at buffer+size as the refcount (used during DOD) - or increment bufstart by sizeof(int), so that the actual allocated memory ptr is at bufstart - sizeof(int). But that has to be consistent for strings and plain buffers. 4) Several Parrot_allocate_zeroed could be just Parrot_allocate as the memory is either copied over or initialized later. And finally a remark WRT COWed Buffers: 5) cow_copy_context() could still be wrong. Both contexts share the same Buffer header. When now this shared buffer header is marked COW each change to the context would unshare the buffer by creating a distinct copy. This also means, that if the COWed stack copy isn't changed in the Sub and after return from the Sub an item is pushed on that stack, it would be copied. I know that I did this for other buffers in the context but it is wrong somehow - IMHO. COWed strings also seem to suffer from that problem. Both buffer headers are marked COW. Even if the shared copy goes out of scope, the COW flag remains - so changing that string later would do a copy of the buffer first, which isn't needed as there is only one user of the buffer left. It could be simpler if we have an explicit refcount for COWed objects. We need that during DOD anyway with some overhead. Takers for these steps wanted, please drop a short note. thanks, leo
Re: [PATCH] Continuations now close over register stacks
At 1:02 AM -0500 1/9/04, Michal Wallace wrote: I changed my compiler to call savetop before every function call, and that passes my tests but I'm having trouble visualizing why. Would I ever NOT want to call savetop before creating a continuation? Sure. The only reason to call savetop is if you want to save R16-31 of all four register sets. The only reason you'd do this is if you actually *care* about the contents of those four sets. If you don't care about one or more set, for example because your code is entirely PMC based and thus doesn't use the I, S, or N registers, you wouldn't -- it's a waste. Also, if your compiler's code analysis determines that none of the registers of a particular set are read without a previous write, then there'd be no reason to save that set. It's a matter of tracking register content lifetimes -- if all the registers in a set are effectively dead there's no reason to preserve the contents on the stack. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] Continuations now close over register stacks
Michal Wallace [EMAIL PROTECTED] wrote: newsub $P1, .Continuation, done For returning just use a .RetContinuation. Or still better, just omit $P1 totally here: .pcc_call $P0, $P1 leo
Re: [PATCH] Continuations now close over register stacks
Luke Palmer [EMAIL PROTECTED] wrote: .sub __main__ newsub $P0, .Closure, _func savetop No - not for plain subroutines/closures. Or you could do as PCC does and use a .RetContinuation, which doesn't close over the stacks, when you don't actually need a full continuation. Yep. Luke leo
Re: [PATCH] Continuations now close over register stacks
Michal Wallace writes: On Thu, 8 Jan 2004, Luke Palmer wrote: .sub __main__ newsub $P0, .Closure, _func savetop newsub $P0, .Continuation, done So the restoretop after the invoke has something to pop (and so your register state isn't screwed up when you get back). Thanks Luke. I changed my compiler to call savetop before every function call, and that passes my tests but I'm having trouble visualizing why. Would I ever NOT want to call savetop before creating a continuation? Very rarely would you not savetop before creating a *real* continuation. But again, very rarely would you actually create a *real* continuation (depending on your language). RetContinuations are almost always a better choice for traditional languages, and languages like Python with no support for continuations. You won't get in trouble mixing RetContinuations with real ones, as long as you don't try to use RetContinuations like Continuations, and only use them to return downward. Luke
Re: [PATCH] Continuations now close over register stacks
On Fri, 9 Jan 2004, Leopold Toetsch wrote: Michal Wallace [EMAIL PROTECTED] wrote: newsub $P1, .Continuation, done For returning just use a .RetContinuation. Or still better, just omit $P1 totally here: .pcc_call $P0, $P1 Aha! I like that even better. :) Thanks! Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: [PATCH] Continuations now close over register stacks
On Fri, 9 Jan 2004, Luke Palmer wrote: Very rarely would you not savetop before creating a *real* continuation. But again, very rarely would you actually create a *real* continuation (depending on your language). RetContinuations are almost always a better choice for traditional languages, and languages like Python with no support for continuations. Gotcha. It just looked odd to me that you had to call savetop... But now I see that's because I was doing the wrong thing all along. :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
re: [PATCH] Continuations now close over register stacks
Luke Palmer wrote: This patch re-implements the register backing stacks as PObjs (so they can be garbage-collected), honors their COW flags, and adds them to the interpreter context (where they should be, honest!). As a healthy side-effect, it encapsulates their behavior nicely into register.c, when before their guts were splattered all over the source. Hey Luke, I applied this patch, ran make realclean and rebuilt parrot. All the parrot tests pass (except the two about numbers, and I think they were failing before) but it doesn't like the code that pirate's generating. I boiled the problem down to this: ### .sub __main__ newsub $P0, .Closure, _func newsub $P1, .Continuation, done .pcc_begin non_prototyped .pcc_call $P0, $P1 done: .local object result .result result .pcc_end print result print \n end .end .pcc_sub _func non_prototyped .local object res res = new PerlString res = hello! .pcc_begin_return .return res .pcc_end_return .end When I run this, parrot says: No more I register frames to pop! I think the problem is coming from the .pcc_begin_return line. This code works fine if I change the .Continuation to a .Closure or .Coroutine... It also worked before the patch. Do I have my calling conventions screwed up or is this a bug? Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: [PATCH] Continuations now close over register stacks
Michal Wallace writes: Luke Palmer wrote: This patch re-implements the register backing stacks as PObjs (so they can be garbage-collected), honors their COW flags, and adds them to the interpreter context (where they should be, honest!). As a healthy side-effect, it encapsulates their behavior nicely into register.c, when before their guts were splattered all over the source. Hey Luke, I applied this patch, ran make realclean and rebuilt parrot. All the parrot tests pass (except the two about numbers, and I think they were failing before) but it doesn't like the code that pirate's generating. I boiled the problem down to this: ### .sub __main__ newsub $P0, .Closure, _func newsub $P1, .Continuation, done .pcc_begin non_prototyped .pcc_call $P0, $P1 done: .local object result .result result .pcc_end print result print \n end .end .pcc_sub _func non_prototyped .local object res res = new PerlString res = hello! .pcc_begin_return .return res .pcc_end_return .end When I run this, parrot says: No more I register frames to pop! I think the problem is coming from the .pcc_begin_return line. This code works fine if I change the .Continuation to a .Closure or .Coroutine... It also worked before the patch. Do I have my calling conventions screwed up or is this a bug? Your calling conventions are screwed up. I'm glad this failed, as I was anticipating this failure and it didn't come up anywhere in the tests! If you unroll what .pcc_call is doing, you might see the problem: .pcc_begin non_prototyped .pcc_call $P0, $P1 done: .local object result .result result .pcc_end Turns into: @pcc_sub_call_4: set P0, P17 set P1, P16 set I0, 0 set I1, 0 set I2, 0 set I3, -2 updatecc savetop invoke done: restoretop set P16, P5 When the continuation is invoked, that savetop it just did is completely nullified, and you're back to the state before you created the continuation. So, in order to get this to work properly, your first four lines must be: .sub __main__ newsub $P0, .Closure, _func savetop newsub $P0, .Continuation, done So the restoretop after the invoke has something to pop (and so your register state isn't screwed up when you get back). Or you could do as PCC does and use a .RetContinuation, which doesn't close over the stacks, when you don't actually need a full continuation. Hope this helped, Luke
Re: [PATCH] Continuations now close over register stacks
On Thu, 8 Jan 2004, Luke Palmer wrote: @pcc_sub_call_4: set P0, P17 set P1, P16 set I0, 0 set I1, 0 set I2, 0 set I3, -2 updatecc savetop invoke done: restoretop set P16, P5 When the continuation is invoked, that savetop it just did is completely nullified, and you're back to the state before you created the continuation. So, in order to get this to work properly, your first four lines must be: .sub __main__ newsub $P0, .Closure, _func savetop newsub $P0, .Continuation, done So the restoretop after the invoke has something to pop (and so your register state isn't screwed up when you get back). Thanks Luke. I changed my compiler to call savetop before every function call, and that passes my tests but I'm having trouble visualizing why. Would I ever NOT want to call savetop before creating a continuation? Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
