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
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
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 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
> >
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
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
26 matches
Mail list logo
