Newsgroups: perl.perl6.internals
Path: g2news1.google.com!news4.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <uberm...@gmail.com>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 1509 invoked from network); 30 Nov 2004 15:10:17 -0000
Received: from x1.develooper.com (63.251.223.170)
  by lists.develooper.com with SMTP; 30 Nov 2004 15:10:17 -0000
Received: (qmail 16162 invoked by uid 225); 30 Nov 2004 15:10:17 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 16157 invoked by alias); 30 Nov 2004 15:10:16 -0000
X-Spam-Status: No, hits=-4.9 required=8.0
	tests=BAYES_00
X-Spam-Check-By: la.mx.develooper.com
Received-SPF: pass (x1.develooper.com: domain of uberm...@gmail.com designates 64.233.184.202 as permitted sender)
Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.202)
  by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Tue, 30 Nov 2004 07:10:11 -0800
Received: by wproxy.gmail.com with SMTP id 67so34283wri
        for <perl6-intern...@perl.org>; Tue, 30 Nov 2004 07:10:05 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=eLYzNN7fxiUgfeu4Aotu/bwmq9S7iInVWCe6IYMNkDPhaoRL5syB2SYM1btgL0jZ16H2mjdVkIPXfn7Pk8L8ps7FnPqTxgoCVtQt8Vu8UqzgX9GFv8+PrkgVEqdNuXvTQ87rSpoWJU+9rOQh53t84c9P0ZZaYjcj8/8+PcgThh8=
Received: by 10.54.21.20 with SMTP id 20mr105241wru;
        Tue, 30 Nov 2004 07:10:05 -0800 (PST)
Received: by 10.54.42.60 with HTTP; Tue, 30 Nov 2004 07:10:05 -0800 (PST)
Message-ID: <f2601a7f041130071078cc459c@mail.gmail.com>
Date: Tue, 30 Nov 2004 10:10:05 -0500
Reply-To: Matt Fowles <uberm...@gmail.com>
To: Dan Sugalski <d...@sidhe.org>
Subject: Re: continuation enhanced arcs
Cc: Jeff Clites <jcli...@mac.com>, Piers Cawley <pdcaw...@bofh.org.uk>, 
	perl6-intern...@perl.org, l...@toetsch.at
In-Reply-To: <a0620072bbdd237e8bc5b@172.24.18.155>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <6f9c15f804112211493f2d9...@mail.gmail.com>
	 <m2llcp1t3o....@obelisk.bofh.org.uk>
	 <200411260710.iAQ7AaS27...@thu8.leo.home>
	 <m2hdnc1685....@obelisk.bofh.org.uk>
	 <200411270705.iAR757R19...@thu8.leo.home>
	 <m2d5xy1c7z....@obelisk.bofh.org.uk>
	 <77145974-41EB-11D9-A00B-000393A6B...@mac.com>
	 <a06200727bdd225064...@172.24.18.155>
	 <f2601a7f041130063625889...@mail.gmail.com>
	 <a0620072bbdd237e8b...@172.24.18.155>
Approved: n...@nntp.perl.org
From: uberm...@gmail.com (Matt Fowles)

Dan~


On Tue, 30 Nov 2004 09:49:54 -0500, Dan Sugalski <d...@sidhe.org> wrote:
> At 9:36 AM -0500 11/30/04, Matt Fowles wrote:
> 
> 
> >Dan~
> >
> >
> >On Tue, 30 Nov 2004 08:28:35 -0500, Dan Sugalski <d...@sidhe.org> 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
> >>  >>following is true:
> >>  >>
> >>  >>1. The variable is referred to again (lexically) after the function has
> >>  >>    returned.
> >>  >>2. The variable is used as the argument of a function call within the
> >>  >>    current compilation unit.
> >>  >
> >>  >That doesn't solve it, though you'd think it would. Here's the
> >>  >counter-example:
> >>  >
> >>  >       x = 1
> >>  >       foo()
> >>  >       print x
> >>  >       y = 2
> >>  >       return y
> >>  >
> >>  >You'd think that x and y could use the same memory location
> >>  >(register, variable--whatever), since ostensibly their lifetimes
> >>  >don't overlap. But continuation re-invocation can cause foo() to
> >>  >return multiple times, and each time it should print "1", but it
> >>  >won't if x and y use the same "slot" (it would print "2" each time
> >>  >after the first). In truth, their lifetimes do overlap, due to the
> >>  >hidden (potential) loops created by continuations.
> >>
> >>  Except... we've already declared that return continuations are
> >>  special, and preserve the registers in the 16-31 range. So when we
> >>  return from foo, regardless of how or how many times, the pointer to
> >>  x's PMC will be in a register if it was in there before the call to
> >>  foo, if it's in the preserved range. So in this case there's no
> >>  problem. Things'll look like:
> >>
> >>         x = 1 # new P16, .Integer; P16 = 1 # P16 has pointer value 0x04
> >>         foo() # foo invocation
> >>         print x # P16 still has pointer value 0x04
> >>         y = 2 # new P16, .Integer; P16 = 2 # P16 now has pointer value 0x08
> >>         return y # Passes back 0x08
> >>
> >>  With more or less clarity.
> >
> >I think that the concern is for the circumstance where foo() promotes
> >it return continuation to a full continuation.  Then, that guarantee
> >is no longer provided (I think), and repeated invocation could leave y
> >in P16 rather than x.
> 
> Nope. The guarantee's still there. Promotion will force things up the
> call chain to get marked as un-recyclable, but registers still get
> restored on invocation.

In that case, I am confused.  When does the guarantee NOT apply?

Thanks,
Matt
-- 
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???