Sounds like "threads" to me.
What I see that's different from common threads in other languages is
that they are all the same, rather than one master and many new threads
that have no context history above them. In Perl 6, every thread sees
the same dynamic scope as the original. It doesn't
Andrew Whitworth wrote:
> The issue mentioned in the Synopses is that junctions autothread, and
> autothreading in a conditional could potentially create multiple
> threads of execution, all of which are taking different execution
> paths. At some point, to bring it all back together again, the var
Em Ter, 2009-05-26 às 19:33 -0700, Jon Lang escreveu:
> "The exact semantics of autothreading with respect to control
> structures are subject to change over time; it is therefore erroneous
> to pass junctions to any control construct that is not implemented via
> as a normal single or multi dispat
On Tue, May 26, 2009 at 8:05 PM, John M. Dlugosz
<2nb81l...@sneakemail.com> wrote:
> Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:
>>
>> >From S09, under Junctions:
>>
>> "The exact semantics of autothreading with respect to control
>> structures are subject to change over time; it is therefore
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:
>From S09, under Junctions:
"The exact semantics of autothreading with respect to control
structures are subject to change over time; it is therefore erroneous
to pass junctions to any control construct that is not implemented via
as a normal sing
Am Samstag, 12. August 2006 17:55 schrieb Bob Rogers:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>See "Method Overloading and GC Issues" in Cfunc.pod. The only way
>IMHO to avoid this problem is to run GC at "safe" points at the
>runloop level . . .
>
> Had you considered keeping t
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 14:00:19 +0200
The continuation barrier is only one nastyness of inferior runloops. The
second problem with it is that it heavily influences the guts of garbage
collection . . .
See "Method Overloading and GC Issu
Am Sonntag, 6. August 2006 17:20 schrieb Bob Rogers:
>The problem is that inferior runloops cannot be re-entered via
> continuation. One example (out of many) is the delegate pmclass, which
> uses inferior runloops in vtable methods to run bytecode. The resulting
> call structure (mixing byte
Bob Rogers wrote:
There are two broad solutions:
1. Restrict continuations to move only "outward", which makes it
unnecessary to restart inferior runloops. This may not be as bad as it
seems, as most of the languages I can think of can be implemented using
only outward (returning) conti
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 19:43:31 +0200
Am Sonntag, 6. August 2006 17:20 schrieb Bob Rogers:
[ a much more detailed answer will follow ]
> ? ?The problem is that inferior runloops cannot be re-entered via
> continuation. ?
C is an exce
Am Sonntag, 6. August 2006 17:20 schrieb Bob Rogers:
[ a much more detailed answer will follow ]
> The problem is that inferior runloops cannot be re-entered via
> continuation.
C is an excellent example for the POC. I've a first question
though: assuming that we might want to eliminate in
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
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,
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.
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, Ma
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:
> >>
> >>
> >>
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
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 continu
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 v
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 w
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
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
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 Rub
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 create
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,
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:
> >> >
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
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(
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 <[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
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?
>
> Imagi
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 cou
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 coul
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
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
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
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 b
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 C after the call.
Oops.
It seems that, in term of cache loc
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" C then yes, this is what
continuations are doing. But the
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 fe
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 C after the call.
> ... It seems
> that even this function body shows the problem:
Yes, that one is r
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 w
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".
>
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
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 w
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
continu
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
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 comme
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 expose
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 lexic
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 correc
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:
>
> ..
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 tha
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 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 co
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
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 variab
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=[...]; arr2=[.
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 t
Leopold Toetsch wrote:
Matt Fowles <[EMAIL PROTECTED]> wrote:
... Why not just make exception handlers a second
continuation passed to all functions.
... because it is answered in a f'up to a similar proposal by our
summarizer:
,--[ leo ]---
Matt Fowles <[EMAIL PROTECTED]> wrote:
> All~
> This got warnocked
Only indirectly ...
> ... Why not just make exception handlers a second
> continuation passed to all functions.
... because it is answered in a f'up to a similar proposal by our
summarizer:
,--[ leo ]--
All~
This got warnocked when last I sent it, so I will try again as I think
it is a reasonable idea.
I am not sure that I understand why we deal with exception handlers in
the current manner. Why not just make exception handlers a second
continuation passed to all functions. Then you call co
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 conti
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"
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
*anythin
All~
I am not sure that I understand why we deal with exception handlers at
all. Why not just make exception handlers a second continuation passed
to all functions. Then you call continuation 1 for successful returns
and continuation 2 for exceptions. This will not introduce overhead to
the
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
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
At 8:33 PM +0100 3/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 7:00 PM +0100 3/22/04, Leopold Toetsch wrote:
D'oh! (I should edit this all out but, well...) If we go with a one
frame stack chunk then we don't have to bother with COW-ing
*anything* with the stack. W
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 7:00 PM +0100 3/22/04, Leopold Toetsch wrote:
> D'oh! (I should edit this all out but, well...) If we go with a one
> frame stack chunk then we don't have to bother with COW-ing
> *anything* with the stack. Which makes the differentiation between a
> re
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?
leo
At 7:00 PM +0100 3/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Since this has gotten to be an issue...
Making a continuation conceptually has three steps. One must:
1) Copy the current environment contents to the continuation
2) Note the bytecode address at which the
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Since this has gotten to be an issue...
> Making a continuation conceptually has three steps. One must:
> 1) Copy the current environment contents to the continuation
> 2) Note the bytecode address at which the continuation should run
> 3) Mark the stacks
Piers Cawley <[EMAIL PROTECTED]> wrote:
> So why does the generated pasm work where the PIR doesn't?
The generated PASM is all one compilation unit. Your (local) labels are
fixed up properly. In your PIR code you had local labels (w/o)
underscore refering to different compilation units.
> I can
Piers Cawley <[EMAIL PROTECTED]> wrote:
[ Continuation usage ]
> Dan? Could you mandate this? Please?
As long as there are no usage patterns that precisely describe how
Continuations should work and how a PIR syntax could look like, there is
little to mandate ;)
> Preserving self and the curren
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 sta
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
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
I don't know about the continuation stuff, but you can't assume that
running imc --> pasm --> exec does the same thing as imc --> exec. I
ran into that before, and I don't think its going to get fixed until
the new imcc lands, at which point old-school pasm might even be
gone (although I don't know
At 11:07 AM +0100 1/13/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ stack layout ]
I'd rather not have the store statically inside the hunk:
- small objects code currently has an upper limit for sized header pools
Doesn't mean we have to use them, honestly. A separate ar
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ stack layout ]
>>I'd rather not have the store statically inside the hunk:
>>- small objects code currently has an upper limit for sized header pools
> Doesn't mean we have to use them, honestly. A separate arena for them
> is fine.
Each sized item (a B
At 5:47 PM +0100 1/12/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
struct hunk {
struct pobj header;
INTVAL used;
INTVAL avail;
Only one of these is needed (and currently used: "used")
struct hunk *upchain;
struct regframe RegisterFram
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> struct hunk {
> struct pobj header;
> INTVAL used;
> INTVAL avail;
Only one of these is needed (and currently used: "used")
> struct hunk *upchain;
> struct regframe RegisterFrame[FRAMES_PER_HUNK];
I'd rather not have t
Picking the last entry in this thread to reply to...
Here's the scoop with register stacks, stacks in general, and continuations.
The pointers to all these stack tops *should* be part of a
continuation, the same as the registers themselves should be. When a
continuation is taken, all the frames
On Jan 8, 2004, at 4:24 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
I think I'm just being dense, but looking at
include/parrot/interpreter.h it appears that they are in the context:
Sorry, yes. They are in the context but not saved. I mixed that up with
the registers themse
Jeff Clites <[EMAIL PROTECTED]> wrote:
> I think I'm just being dense, but looking at
> include/parrot/interpreter.h it appears that they are in the context:
Sorry, yes. They are in the context but not saved. I mixed that up with
the registers themselves, which went out of the context.
leo
On Jan 7, 2004, at 8:15 PM, Melvin Smith wrote:
Leopold Toetsch writes:
> Jeff Clites <[EMAIL PROTECTED]> wrote:
> > On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
> Exactly the latter:
> That was AFAIK a design decision, when Dan did introduce CPS. At
this
> time register backing stacks went
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.
>> > >> *B
Melvin Smith writes:
> The downside to our implementation is in the return continuation case.
> The common case is to create the continuation that you plan to
> return with, and you already know there will be no need for
> copy-on-write in most cases because typically the execution
> path will retu
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 interp
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 w
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 p
On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
It makes each chunk into a subclass of Buffer like so:
struct RegisterChunkBuf {
size_t used;
PObj* next;
};
That part is already answered: create a buffer_like structure.
*But* again
Luke Palmer <[EMAIL PROTECTED]> wrote:
> It makes each chunk into a subclass of Buffer like so:
> struct RegisterChunkBuf {
> size_t used;
> PObj* next;
> };
That part is already answered: create a buffer_like structure.
*But* again register backing stacks are *not* in the
On Jan 6, 2004, at 6:42 PM, Luke Palmer wrote:
Jeff Clites writes:
On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
It makes each chunk into a subclass of Buffer like so:
struct RegisterChunkBuf {
size_t used;
PObj* next;
};
To do that properly, I think you need a pobj_t as the
At 04:41 PM 1/6/2004 -0700, Luke Palmer wrote:
I want these things to be garbage collected, but DOD doesn't trace the
buffer. I can't seem to find a way to mark the frames without making
the chunks into PMCs (yuck). Is there a way to do this?
I was about to answer your question when I saw your f
Jeff Clites writes:
> On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
>
> >Leopold Toetsch writes:
> >>
> >>Good. Pass it over to me :) COW copy of stacks and of other
> >>buffer-based
> >>items is still broken. These need distinct headers so that they work
> >>like COWed strings.
> >
> >Alright,
On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
Leopold Toetsch writes:
Good. Pass it over to me :) COW copy of stacks and of other
buffer-based
items is still broken. These need distinct headers so that they work
like COWed strings.
Alright, I've got a pretty big incomplete patch here (see, when
Leopold Toetsch writes:
> Melvin Smith wrote:
>
> >At 07:53 AM 1/6/2004 -0700, Luke Palmer wrote:
> >
> >>Aren't continuations supposed to close over the register stacks? In
> >>this code:
> >
> >Currently the Copy-On-Write bit isn't being honored on the register pad
> >stacks,
>
> No. Register
Melvin Smith wrote:
At 07:53 AM 1/6/2004 -0700, Luke Palmer wrote:
Aren't continuations supposed to close over the register stacks? In
this code:
Currently the Copy-On-Write bit isn't being honored on the register pad
stacks,
No. Register backing stacks are no more in the interpreter context an
1 - 100 of 152 matches
Mail list logo
