Matt Fowles [EMAIL PROTECTED] wrote:
... Thus you can consider all of the
following questions (even though they will be phrased as statements).
1) After a full continuation is taken all of the registers must be
considered invalid.
Calling a subroutine allocates a new register frame, that
Leo~
Thanks for the clarification.
Matt
On Wed, 17 Nov 2004 08:48:58 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Matt Fowles [EMAIL PROTECTED] wrote:
... Thus you can consider all of the
following questions (even though they will be phrased as statements).
1) After a full
Matt Fowles [EMAIL PROTECTED] wrote:
[ continuations should restore registers ]
I am sorry, but I don't understand what you are trying to say here.
Would you mind rewording it for me?
Imagine a simple loop:
i = 0
lp:
foo()
inc i
if i 10 goto lp
Looking at the loop counter
Leo~
On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Matt Fowles [EMAIL PROTECTED] wrote:
[ continuations should restore registers ]
I am sorry, but I don't understand what you are trying to say here.
Would you mind rewording it for me?
Imagine a simple
Matt Fowles [EMAIL PROTECTED] wrote:
Leo~
On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
i = 0
lp:
foo()
inc i
if i 10 goto lp
There is one thing I am not sure about here. The loop will work
correctly for each seperate invocation of the
Leo~
On Tue, 16 Nov 2004 16:37:04 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Matt Fowles [EMAIL PROTECTED] wrote:
Leo~
On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch [EMAIL PROTECTED]
wrote:
i = 0
lp:
foo()
inc i
if i 10 goto lp
There is
At 11:52 AM -0500 11/16/04, Matt Fowles wrote:
Leo~
On Tue, 16 Nov 2004 16:37:04 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Matt Fowles [EMAIL PROTECTED] wrote:
Leo~
On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch [EMAIL PROTECTED]
wrote:
i = 0
lp:
foo()
inc i
Matt Fowles wrote:
I disagree with that analysis. Let us consider the actual effect of
such an implementation.
First iteration
i = 0;
foo(); #at this point a continuation created capturing i=0, promoted
by Jens and stuff happens
#eventually it is invoked, restoring i=0
i++; #i = 1
foo(); #at this
Dan~
On Tue, 16 Nov 2004 12:29:19 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:52 AM -0500 11/16/04, Matt Fowles wrote:
Leo~
On Tue, 16 Nov 2004 16:37:04 +0100, Leopold Toetsch [EMAIL PROTECTED]
wrote:
Matt Fowles [EMAIL PROTECTED] wrote:
Leo~
On Tue, 16 Nov
On Nov 15, 2004, at 10:29 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
Picture this call stack:
main -- A -- B -- C -- D -- E
The call from D to E uses the RESUMEABLE label, and E stores the
resulting continuation in a global, and everything up to main returns.
Then, main
Leo~
On Tue, 16 Nov 2004 18:32:07 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Matt Fowles wrote:
I disagree with that analysis. Let us consider the actual effect of
such an implementation.
First iteration
i = 0;
foo(); #at this point a continuation created capturing i=0,
On Nov 16, 2004, at 10:03 AM, Matt Fowles wrote:
Since both you and Leo are arguing against me here, it seems like that
I am wrong, but I would like to figure out exactly why I am wrong so
that I can correct my train of thought in the future.
Here's a real example you can play with, if you have
At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
The continuation preserves the frame (the mapping from logical
variables to their values), but not the values of those variables at
the time the continuation was created.
This is one of the fundamental properties of continuations, but it
does throw
Jeff Clites [EMAIL PROTECTED] wrote:
sub B
{
a = 1
foo()
print a
b = 2
return b
}
If something called by foo() captures a continuation, and something
invokes it after B() returns, then there's a hidden branch, in effect,
from the return to the print,
Dan~
On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
The continuation preserves the frame (the mapping from logical
variables to their values), but not the values of those variables at
the time the continuation was
At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
The continuation preserves the frame (the mapping from logical
variables to their values), but not the values of those
Dan~
On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
The continuation preserves the
At 3:39 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:32 AM -0800 11/16/04, Jeff Clites
Dan~
On Tue, 16 Nov 2004 15:54:48 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 3:39 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16
At 4:10 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 15:54:48 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 3:39 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 3:12 PM -0500 11/16/04, Matt Fowles
Dan~
On Tue, 16 Nov 2004 16:24:06 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
We could, but it would be wrong. Hell, it's arguably wrong for return
continuations to do so, and it wouldn't be unreasonable to argue that
I and N register contents are guaranteed crud and required refetching.
On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
Matt Fowles [EMAIL PROTECTED] wrote:
Yes, but in the case of the continuation resuming after foo, the
continuation should restore the frame to the point where it was taken.
Thus all of the registers will be exactly as they were when the
Jeff Clites writes:
On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
Matt Fowles [EMAIL PROTECTED] wrote:
Yes, but in the case of the continuation resuming after foo, the
continuation should restore the frame to the point where it was taken.
Thus all of the registers will be exactly
Dan Sugalski [EMAIL PROTECTED] wrote:
At 5:53 PM +0100 11/13/04, Leopold Toetsch wrote:
As the analysis of test errors of the new reigster allocator has
shown, we have a problem WRT register allocation. This problem isn't
new, but as the allocator is more efficiently reusing registers (or
reusing
Luke Palmer [EMAIL PROTECTED] wrote:
Jeff Clites writes:
a = 1
foo()
print a
b = 10
return b
It would seem (w/o continuations) that b should be able to re-use a's
register, but if it does then we'll print 10 instead of 1 the second
time.
It can. You can't
Bill Coffman [EMAIL PROTECTED] wrote:
On Sun, 14 Nov 2004 17:03:33 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
We don't really have that much of a problem. What we have is just
something more simple -- the target of a continuation marks the start
of a basic block. That means that we have to
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
Yes, but Jeff's example wasn't really reflecting the problem.
How come?
Your code didn't reuse Ca after the call.
... It seems
that even this function body shows the problem:
Yes, that one is
All~
I think I may know a way around this problem. You will have to bear
with me for a moment as I am not entirely used to speaking in terms of
continuations (I find a similar difficulty in speaking about Math, but
at least I have a commonly accepted lexicon for that ;-).
The view from 10,000
Matt Fowles [EMAIL PROTECTED] wrote:
All~
... When a full continuation is invoked it
*copies* its contenxt into place (thus it can be invoked multiple
times and it will always have its original context).
If you mean by context Cstruct Parrot_Context then yes, this is what
continuations are
On Nov 15, 2004, at 3:27 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
Yes, but Jeff's example wasn't really reflecting the problem.
How come?
Your code didn't reuse Ca after the call.
Oops.
It seems that, in term of cache
On Mon, Nov 15, 2004 at 09:51:58AM +0100, Leopold Toetsch wrote:
: Yes, as said I'm fine too with that. Perl/Python will do that anyway.
: But what about other languages? Are we forcing these to be as dynamic as
: the primary HLL targets?
In Perl 6, any assumptions that cause inefficiency should
At 9:16 AM -0800 11/15/04, Larry Wall wrote:
On Mon, Nov 15, 2004 at 09:51:58AM +0100, Leopold Toetsch wrote:
: Yes, as said I'm fine too with that. Perl/Python will do that anyway.
: But what about other languages? Are we forcing these to be as dynamic as
: the primary HLL targets?
In Perl 6, any
Jeff Clites [EMAIL PROTECTED] wrote:
Picture this call stack:
main -- A -- B -- C -- D -- E
The call from D to E uses the RESUMEABLE label, and E stores the
resulting continuation in a global, and everything up to main returns.
Then, main invokes the continuation, and we find
Leo~
On Mon, 15 Nov 2004 20:30:18 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Matt Fowles wrote:
Leo~
On Mon, 15 Nov 2004 17:36:20 +0100, Leopold Toetsch [EMAIL PROTECTED]
wrote:
Matt Fowles wrote:
I do mean context + registers and it can do that. If you keep your
On Mon, 15 Nov 2004 17:19:01 -0500, Matt Fowles [EMAIL PROTECTED] wrote:
Which gives me an evil idea. We could allow bytecode to specify that
it wanted to start taking full continuations everywhere, but that
these would never be used below it on the callstack. Thus the regex
engine could do
Matt Fowles [EMAIL PROTECTED] wrote:
Jeff~
Yes, but in the case of the continuation resuming after foo, the
continuation should restore the frame to the point where it was taken.
Thus all of the registers will be exactly as they were when the
continuation was taken (i.e. in the correct
At 11:01 PM +0100 11/13/04, Leopold Toetsch wrote:
Matt Fowles [EMAIL PROTECTED] wrote:
I get the feeling that this is equivalent to requiring exception
handlers to be a locally defined closure, which is another way we
could go about this.
Yes. That solves it. OTOH going all along with
At 5:53 PM +0100 11/13/04, Leopold Toetsch wrote:
As the analysis of test errors of the new reigster allocator has
shown, we have a problem WRT register allocation. This problem isn't
new, but as the allocator is more efficiently reusing registers (or
reusing them in a different way) it's
On Nov 14, 2004, at 1:53 PM, Dan Sugalski wrote:
Since, for example, it's completely reasonable (well, likely at least)
for a called sub to rebind lexicals in its parent
What does that mean, exactly? It seems like that directly contradicts
the meaning of lexical. For instance, see Larry's
On Sun, 14 Nov 2004 17:03:33 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 5:53 PM +0100 11/13/04, Leopold Toetsch wrote:
As the analysis of test errors of the new reigster allocator has
shown, we have a problem WRT register allocation. This problem isn't
new, but as the allocator is more
As the analysis of test errors of the new reigster allocator has shown,
we have a problem WRT register allocation. This problem isn't new, but
as the allocator is more efficiently reusing registers (or reusing them
in a different way) it's exposed again.
0) The register allocator isn't to
On Nov 13, 2004, at 8:53 AM, Leopold Toetsch wrote:
2) Continuations (t/op/gc_13.imc [Hi Piers])
Again we have a hidden branch done by a Continuation, or better a
loop. The control flow of the main program is basically represented by
this conventional code fragment:
arr1=[...];
All~
On Sat, 13 Nov 2004 10:52:38 -0800, Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 13, 2004, at 8:53 AM, Leopold Toetsch wrote:
We'd have just to force using lexicals for all vars
Having variable-size register sets would solve this, since you could
have fixed assignments of variables to
Matt Fowles [EMAIL PROTECTED] wrote:
I like the idea of mandating lexicals vars. This would also eliminate
the need for spilling (I think), as the register allocator would only
need to refetch the lexical rather than save it off somewhere to be
restored later.
There are two issues: yes with
On Nov 13, 2004, at 11:16 AM, Matt Fowles wrote:
All~
On Sat, 13 Nov 2004 10:52:38 -0800, Jeff Clites [EMAIL PROTECTED]
wrote:
On Nov 13, 2004, at 8:53 AM, Leopold Toetsch wrote:
We'd have just to force using lexicals for all vars
Having variable-size register sets would solve this, since you
Jeff~
On Sat, 13 Nov 2004 14:08:12 -0800, Jeff Clites [EMAIL PROTECTED] wrote:
That's oversimplifying a bit, but I feel like those are the core issues
(stemming from the observation of Leo's that continuations in effect
give all variables a lifetime that extends to their entire block, in
On Nov 13, 2004, at 2:46 PM, Matt Fowles wrote:
On Sat, 13 Nov 2004 14:08:12 -0800, Jeff Clites [EMAIL PROTECTED]
wrote:
That's oversimplifying a bit, but I feel like those are the core
issues
(stemming from the observation of Leo's that continuations in effect
give all variables a lifetime that
Jeff~
On Sat, 13 Nov 2004 17:35:02 -0800, Jeff Clites [EMAIL PROTECTED] wrote:
Not all variables, but due to Leo's case (2), it should be all
variables which are referenced after the first function call out of a
subroutine, if there's a later function call; for instance, consider:
...
48 matches
Mail list logo
