Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 08, 2004 at 04:04:31PM -0500, Matt Fowles wrote:
>> We are (for the moment) assuming that "shift array" somehow causes a
>> full continuations to be taken and then invoked it in a subsequent
>> call. Then this code would infinite loop; howev
On Wed, Dec 08, 2004 at 04:04:31PM -0500, Matt Fowles wrote:
> I would disagree. Let me take the above example and work with it a little:
>
> $I0 = 10
> loop:
> $P0 = shift array
> dec $I0
> if $I0 goto loop
>
> We are (for the moment) assuming that "shift array" somehow causes a
> full
Matt Fowles <[EMAIL PROTECTED]> wrote:
> ... This author may
> have to be a little wary about value vs reference semantics, but
> programmers are fairly used to that pitfall by now.
Yes. But this still boils down to the question, if an author or compiler
knows that a full continuation is involve
[EMAIL PROTECTED] wrote:
What this means is that care must be taken when you are writing code
that you expects to be invoked multiple times. However, if you are a
function that on your second invocation returns via the continuation
from you first invocation, you should probably expect to be called
Leo~
On Wed, 8 Dec 2004 20:29:00 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> So my conclusion that (in combination with restoring registers to the
> values of continuation creation) I,S,N registers are almost unusable is
> correct?
I would disagree. Let me take the above example and wor
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> 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
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 implementa
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 co
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 continu
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
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 mak
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 mak
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 recommendatio
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
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.
>
>
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 co
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
Leo~
On Fri, 3 Dec 2004 09:26:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Ok. I'll try to summarize, where I see the problem. No diagrams, just
> code :)
>
> [snip]
Thanks for the clear explanation. I did not realize that S registers
could switch pointers, that does make things a lit
Leo~
On Fri, 3 Dec 2004 09:26:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Ok. I'll try to summarize, where I see the problem. No diagrams, just
> code :)
>
> [snip]
Thanks for the clear explanation. I did not realize that S registers
could switch pointers, that does make things a li
Luke Palmer wrote:
Frankly I think, I've presented a way to make continuations work
correctly. I did *not* hear any technical or otherwise reasonable
argument that it wouldn't work or that it's untenable, nothing, nada.
Well, since I (and I'm sure many others) have been skipping over a lot
of messa
On 3 Dec 2004, at 09:46, Luke Palmer wrote:
I looked through google groups and couldn't find leo's solution
("putting lexicals in registers", and I can't figure out what that
means; couldn't you have a loop counter that isn't a lexical?).
I believe its the first in the thread 'Lexicals, continuatio
And because of a message that came up very recently, I infer that leo's
solution involves a variable-sized register frame.
This sounds like a much better solution than the one I've just proposed.
No saving/restoring, the register frame size is known at compile time
(so the double-indirection can
Very embarrassing delurk just to say...
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
[hyuuuge snip]
> Perl6 syntax like "my int $i;" would need PMCs. Extracting an integer
> from an array that stores natural ints would need a PMC.
Someone please listen to this man! In my opinion, one of the b
I looked through google groups and couldn't find leo's solution
("putting lexicals in registers", and I can't figure out what that
means; couldn't you have a loop counter that isn't a lexical?).
I think we all agree that this is a major problem, and that to ignore it
would be a fatal mistake in Pa
Leopold Toetsch writes:
> > I think we have basically 3 choices: support continuations such that
> > they work correctly in all HLL situations and accept likely poor
> > performance, or support only escape continuations, or devise a strategy
> > whereby Parrot itself doesn't provide continuations,
[EMAIL PROTECTED] wrote:
I think we have basically 3 choices: support continuations such that
they work correctly in all HLL situations and accept likely poor
performance, or support only escape continuations, or devise a
strategy whereby Parrot itself doesn't provide continuations, but
allows
Matt Fowles <[EMAIL PROTECTED]> wrote:
> All~
> I must admit I am a little confused as to what the problem is. Given
> that any continuation which was originally created as a return
> continuation will restore its registers, all code which uses P/S
> registers will work as expected. Furthermore,
All~
I must admit I am a little confused as to what the problem is. Given
that any continuation which was originally created as a return
continuation will restore its registers, all code which uses P/S
registers will work as expected. Furthermore, I/N registers will be
usable accross function ca
Jeff Clites <[EMAIL PROTECTED]> wrote:
> I think Leo originally brought up the "labeling" idea,
Yes, one of the first ideas I had. I've tossed it later for similar
reasons you are showing here with the ruby example. It just doesn't
work. The second was refetching from lexicals. I tossed it later
On Dec 1, 2004, at 10:27 PM, Bill Coffman wrote:
First, consider my original post in this thread:
http://www.nntp.perl.org/group/perl.perl6.internals/27383
To summarize:
Full continuations are powerful but expensive. They are like hidden
goto's and add arcs to the control flow graph. This cause
All,
As with most technical problems, fully specifying them, is often half
the battle. In this case, I think we're getting close to
understanding the issues at least.
[please treat all statements as possible questions]
First, consider my original post in this thread:
http://www.nntp.perl.org/gr
Jeff Clites <[EMAIL PROTECTED]> wrote:
> But so it sounds like I and N registers are a bit of a waste then, no?
A bit? They would be utterly useless.
As a plain:
add Px, Py, Pz
(as well as almost any other PMC related opcode) can be overloaded by
running a PASM/PIR function, there is no usag
On Dec 1, 2004, at 7:23 AM, Dan Sugalski wrote:
At 12:06 AM -0800 12/1/04, Jeff Clites wrote:
On Nov 30, 2004, at 11:45 AM, Dan Sugalski wrote:
In this example:
% cat continuation6.ruby
def strange
callcc {|continuation| $saved = continuation}
end
def outer
a = 0
strange()
a = a + 1
At 10:12 PM -0800 11/30/04, Bill Coffman wrote:
On Tue, 30 Nov 2004 14:45:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 11:20 AM -0800 11/30/04, Jeff Clites wrote:
>% cat continuation6.ruby
>def strange
> callcc {|continuation| $saved = continuation}
>end
>
>def outer
> a = 0
At 12:06 AM -0800 12/1/04, Jeff Clites wrote:
On Nov 30, 2004, at 11:45 AM, Dan Sugalski wrote:
In this example:
% cat continuation6.ruby
def strange
callcc {|continuation| $saved = continuation}
end
def outer
a = 0
strange()
a = a + 1
print "a = ", a, "\n"
end
Through the joys
Bill~
On Tue, 30 Nov 2004 22:12:30 -0800, Bill Coffman <[EMAIL PROTECTED]> wrote:
> On Tue, 30 Nov 2004 14:45:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>
> > At 11:20 AM -0800 11/30/04, Jeff Clites wrote:
> > >% cat continuation6.ruby
> > >def strange
> > > callcc {|continuation|
Bill Coffman writes:
> I can see that there is true magic in the power of using references in
> this way. Nonetheless, how can the compiler figure out that it can't
> use an integer here? The compiler should use integers when it can,
> but it sounds like you are saying that when a variable crosse
On Nov 30, 2004, at 11:45 AM, Dan Sugalski wrote:
In this example:
% cat continuation6.ruby
def strange
callcc {|continuation| $saved = continuation}
end
def outer
a = 0
strange()
a = a + 1
print "a = ", a, "\n"
end
Through the joys of reference types, a will continue to increas
On Tue, 30 Nov 2004 14:45:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:20 AM -0800 11/30/04, Jeff Clites wrote:
> >% cat continuation6.ruby
> >def strange
> > callcc {|continuation| $saved = continuation}
> >end
> >
> >def outer
> > a = 0
> > strange()
> > a = a + 1
> >
At 11:20 AM -0800 11/30/04, Jeff Clites wrote:
On Nov 30, 2004, at 10:27 AM, Dan Sugalski wrote:
At 10:15 AM -0800 11/30/04, Jeff Clites wrote:
None of this should have anything to do with return continuations
specifically, since this is the case where the body of foo (or
something called from i
Jeff~
On Tue, 30 Nov 2004 11:20:50 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 30, 2004, at 10:27 AM, Dan Sugalski wrote:
>
>
>
> > At 10:15 AM -0800 11/30/04, Jeff Clites wrote:
>
> > Oh. No, it won't. We've declared that return continuations will always
> > leave the top half regi
On Nov 30, 2004, at 10:27 AM, Dan Sugalski wrote:
At 10:15 AM -0800 11/30/04, Jeff Clites wrote:
Oh. No, it won't. We've declared that return continuations will always
leave the top half registers in the state they were when the return
continuation was taken. In this case, when it's taken to pas
Jeff~
On Tue, 30 Nov 2004 10:15:00 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
>
>
>
> On Nov 30, 2004, at 5:28 AM, Dan Sugalski wrote:
>
> > At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
> >> On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
> >>
> >>> I just thought of a heuristic that mig
At 10:15 AM -0800 11/30/04, Jeff Clites wrote:
On Nov 30, 2004, at 5:28 AM, Dan Sugalski wrote:
At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
I just thought of a heuristic that might help with register
preservation:
A variable/register should be pres
On Nov 30, 2004, at 5:28 AM, Dan Sugalski wrote:
At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
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
fo
At 10:10 AM -0500 11/30/04, Matt Fowles wrote:
Dan~
On Tue, 30 Nov 2004 09:49:54 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 9:36 AM -0500 11/30/04, Matt Fowles wrote:
>Dan~
>
>
>On Tue, 30 Nov 2004 08:28:35 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> At 1:45 AM -0800 11/29/04, J
Dan~
On Tue, 30 Nov 2004 09:49:54 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:36 AM -0500 11/30/04, Matt Fowles wrote:
>
>
> >Dan~
> >
> >
> >On Tue, 30 Nov 2004 08:28:35 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
> >>
> >>
> >>
At 9:36 AM -0500 11/30/04, Matt Fowles wrote:
Dan~
On Tue, 30 Nov 2004 08:28:35 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
>On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
>
>>I just thought of a heuristic that might help with register
>>prese
Dan~
On Tue, 30 Nov 2004 08:28:35 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
>
>
> >On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
> >
> >>I just thought of a heuristic that might help with register
> >>preservation:
> >>
> >>A variable/regi
At 2:51 PM +0100 11/29/04, Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
It seems to me that there is no good solution to this problem without
annotating the register set or killing the register allocator.
I think I've proposed a reasonable solution: putting lexicals in
registers.
At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
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 ag
Hello All,
I haven't been able to devote much time lately, but this week I hope
to modify the register allocator to deal with these arcs, as well as
enhancements to the spill code. I expect that in some cases it will
have a definite impact on speed, and others it won't. Most of the test
cases (ma
At 11:06 AM -0500 11/29/04, Matt Fowles wrote:
All~
On Mon, 29 Nov 2004 14:51:43 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
> It seems to me that there is no good solution to this problem without
> annotating the register set or killing the register
All~
On Mon, 29 Nov 2004 14:51:43 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
> > It seems to me that there is no good solution to this problem without
> > annotating the register set or killing the register allocator.
>
> I think I've proposed a re
Luke Palmer <[EMAIL PROTECTED]> wrote:
> It seems to me that there is no good solution to this problem without
> annotating the register set or killing the register allocator.
I think I've proposed a reasonable solution: putting lexicals in
registers.
> Luke
leo
It seems to me that there is no good solution to this problem without
annotating the register set or killing the register allocator. So
perhaps we should keep the non-pmc registers at value semantics; that
is, continuations simply restore their value when the continuation was
taken.
Yes, I know
On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
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
re
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
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 ;)
>
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> 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.
>
> We don't hav
Piers Cawley <[EMAIL PROTECTED]> wrote:
> 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.
We don't have a problem WRT register preservation, the problem ar
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 po
Matt Fowles wrote:
It is also possible for functions to jump forward to the return
continuation of a function called later on
Yes. But I can't see a problem with that. The opcode after an invoke
opcode is already the begin of a new basic block. The forward branch
would just be an additional edge
Bill~
On Mon, 22 Nov 2004 11:49:59 -0800, Bill Coffman <[EMAIL PROTECTED]> wrote:
> >sub1() <---+ <-+
> >... ||
> >sub2() +<-+ |
> >...| |
> >sub3() ---+-+
>
> In the continuations enhanced control fl
Bill Coffman <[EMAIL PROTECTED]> wrote:
> ...volatile, and non-volatile symbols (variables). Non-volatile symbols
> do not cross subroutine calls, and can therefore be put in the lower
> register half.
I've used the terms volatiles and non-volatiles in the reversed sense,
i.e. from the POV of an
kind, there will be spilling.
Here's a list of proposals I have seen to deal with that issue:
1) Let the above stand (I think I was the only one who said that, and
that was before I had really thought about it).
2) Let the above stand, but allow for a pragma to turn off the arcs.
Thus, I
66 matches
Mail list logo
