develooper Front page | perl.perl6.internals | Postings from November 2004

Re: Continuations, basic blocks, loops and register allocation

Thread Previous | Thread Next
From:
Leopold Toetsch
Date:
November 15, 2004 04:03
Subject:
Re: Continuations, basic blocks, loops and register allocation
Message ID:
200411151127.iAFBRJI18629@thu8.leo.home
Jeff Clites <jclites@mac.com> 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<a> after the call.

> ... It seems
> that even this function body shows the problem:

Yes, that one is reflecting it.

> 	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".

Yep, if there is another call that uses the captured continuation of the
foo() call and continues at "print a".

> It seems that, in term of cache locality, the same problem is there
> with more registers v. spilling v. lexicals.

Not quite. We can't extend just one register set, we'd do that for all 4
kinds. You can not easily have 64 PMC registers and just 10 INTVALs.
A lexical access is just an array lookup (at least if the compiler uses
the indexed addressing of lexicals).

> ... That is, if you have 100
> local variables whose lifetimes overlap (due to continuations), then
> you need 100 distinct memory locations to (repeatedly) access.

Sure. If the program is complex you need the storage anyway.

>> 4) Having an explicit syntax construct "(call-with-current-continuation
>> " that expresses verbatim, what's going on, like e.g. with a reserved
>> word placed as a label:
>>
>>   RESUMEABLE: x = choose(arr1)

> I don't think that really helps either: If you have such a call, then
> all the frames higher up the stack also can "return multiple times", so
> they have the behavior, even w/o the label.

The RESUMABLE label is of course at the invocation that might
resume, somehwere up the call chain. Again: the HLL compiler (or the
programmer) knows the effect of the continuation. Just the PIR code is
too dumb, i.e. is lacking this information.

> On the other hand, this Ruby code really bugs me (note: "$" variables
> in Ruby are globals):

> ... , you get an infinite loop, printing increasing
> integers.)

Sure. With callcc you are calling the function again and again.

> JEff

leo

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About