On Fri, Feb 6, 2009 at 8:32 AM, Andrew Whitworth via RT
wrote:
> On Thu Feb 05 18:11:58 2009, pmichaud wrote:
>> I'm okay with closing the ticket, assuming that :unique_reg does
>> indeed cause the register allocation algorithm to be simple.
>> (IIRC, as recently as a
On Thu, Feb 05, 2009 at 08:36:53AM -0800, Andrew Whitworth via RT wrote:
> On Tue Nov 01 09:03:54 2005, pmichaud wrote:
> > From a discussion earlier today on #irc...
> >
> > It would be nice if the PIR compiler had a way to use
> > a very basic register allocati
Dave has left a new comment on your post "Register allocation in a PIR
compiler":
Never mind. Something about this was nagging me, so I went back and
read it again, and it looks like you are not spilling registers at all,
but just reusing dead registers. So my comment doesn't app
Dave has left a new comment on your post "Register allocation in a PIR
compiler":
Hope you don't mind if I mention a couple of points. Presumably
these "freed" registers are being spilled to memory, meaning that they
are assigned to a stack location. I don't see ho
here's a label/symbol conflict.
I think that may be possible. I'll look into it while I'm fixing another bug
in register allocation today.
-- c
On Sat, Jun 14, 2008 at 08:58:22PM -0400, Bob Rogers wrote:
> [...] And
> the easiest fix would be to decide not to support it at all.
+1. Another +1 if we can somehow get IMCC to report an error
when there's a label/symbol conflict.
Pm
From: "James Keenan via RT" <[EMAIL PROTECTED]>
Date: Sat, 14 Jun 2008 17:13:49 -0700
Is there any way we could determine whether this is still a bug? E.g.,
is there any test we could write for it?
If I try to run the code below (in r28330), I get the following error:
[EMAIL
Is there any way we could determine whether this is still a bug? E.g.,
is there any test we could write for it?
cting it to exist.)
The feature could continue to exist -- without the confusion -- by
providing a way to disable register allocation altogether. The IMCC
parseflags function already has code to select between the "vanilla"
allocator and a graph-based allocator depending on optimization level;
On Dec 11, 2007 8:43 AM, Joshua Isom <[EMAIL PROTECTED]
Parrot provides a calling convention, but does not, that I know of,
mandate that calling convention. In any computer, there are multiple
calling conventions used(often leading to a lack of interoperability,
but nevertheless
On Dec 11, 2007 8:43 AM, Joshua Isom <[EMAIL PROTECTED]> wrote:
>
> On Dec 10, 2007, at 10:59 AM, Klaas-Jan Stol wrote:
>
> > In order to draw attention to this point, I changed the subject.
> >
> > Is there anybody who thinks the removal from PIR of $-less registers
> > ("absolute" or PASM regist
On Dec 10, 2007, at 10:59 AM, Klaas-Jan Stol wrote:
In order to draw attention to this point, I changed the subject.
Is there anybody who thinks the removal from PIR of $-less registers
("absolute" or PASM registers) should not be done?
kjs
Parrot provides a calling convention, but does no
ly forgetting about this piece of the
> > specification.
> > I can, however, imagine a situation in which someone would want to do
> > manual register allocation (writing Parrot assembly) for
> > certain cases. I'm not sure whether this manual allocation would be
> > disregard
Klaas-Jan wrote:
There is of course the option of taking the current behavior as
"correct", effectively forgetting about this piece of the
specification.
I can, however, imagine a situation in which someone would want to do
manual register allocation (writing Parrot assembly) for
cer
t;correct", effectively forgetting about this piece of the
specification.
I can, however, imagine a situation in which someone would want to do
manual register allocation (writing Parrot assembly) for
certain cases. I'm not sure whether this manual allocation would be
disregarded by IMCC which then does its own reg. allocation.
kjs
On Friday 07 December 2007 11:22:10 Klaas-Jan Stol wrote:
> According to the spec, this is a bug.
>
> Now, this isn't a big deal, because the semantics of the program aren't
> changed. The only problem I can imagine is for embedders, but I'm not sure
> if you can poke into parrot registers from a
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #48326]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48326 >
ACcording to PDD19:
If you directly reference P99, Parrot will blindly allocate 100 r
On Tue, Nov 27, 2007 at 08:52:32PM -0800, Will Coleda via RT wrote:
> On Wed Apr 04 05:59:18 2007, [EMAIL PROTECTED] wrote:
> > For me, running the attached PIR file outputs:
> > Sub
> > String
> >
> > instead of:
> > Sub
> > Sub
>
> Can anyone reproduce this on the original platform with
> 0.5.
On Wed Apr 04 05:59:18 2007, [EMAIL PROTECTED] wrote:
> ---
> osname= linux
> osvers= 2.6.16-gentoo-r6
> arch= i686-linux
> cc= i686-pc-linux-gnu-gcc
> ---
> Flags:
> category=core
> severity=medium
> ack=no
> ---
> For me, running the attached PIR file outputs:
> Sub
> String
>
# New Ticket Created by "Yehoshua Sapir"
# Please include the string: [perl #42299]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42299 >
---
osname= linux
osvers= 2.6.16-gentoo-r6
arch= i686-linux
cc= i686-pc-linux-
Coke has reported on IRC that the code doesn't fail for him, with OS
X/intel/HEAD.
te:Hi Everyone,Currently IMCC uses a Graph Coloring based Register allocation algorithm.The implementation is a trimmed down version of Brigg's Allocator.I came across this research paper that talks about the new registerallocation algorithm "Linear Scan Allocation"for dynamical
On Thursday 29 June 2006 20:20, Vishal Soni wrote:
> Let me know what your thoughts are and would it be worth implementing this
> algorithm to see how it performs compared to graph coloring algorithm.
>
> Please share your thoughts accordingly
It'd be very useful not only to have two implementati
Hi Everyone,
Currently IMCC uses a Graph Coloring based Register allocation algorithm.
The implementation is a trimmed down version of Brigg's Allocator.
I came across this research paper that talks about the new register
allocation algorithm "Linear Scan Allocation"for dynam
Jerry Gay via RT wrote:
please take another look at this ticket, as the new scheme is now in
effect.
The bug is more unlikely now but else nothing has changed.
~jerry
leo
he PIR compiler had a way to use
a very basic register allocation algorithm for .subs that
use only a small number of registers.
As I understand the current state of things, the PIR compiler
performs a fairly complex analysis of a sub's control flow
in order to make optimal use of registers in the sub
On Jun 28, 2005, at 17:14, Bill Coffman wrote:
Isn't the register allocator pretty much minimized by the new
architecture
implementation? My understanding was that only temporary variables
could
benefit from it now. Perhaps the new changes aren't in effect yet? Just
curious.
The register al
Isn't the register allocator pretty much minimized by the new architecture
implementation? My understanding was that only temporary variables could
benefit from it now. Perhaps the new changes aren't in effect yet? Just
curious.
On 6/28/05, via RT Leopold Toetsch <[EMAIL PROTECTED]>
wrote:
>
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #36407]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36407 >
The register allocator doesn't properly track control flow, if a label
has the same
on of continuations I've posted this idea here:
http://xrl.us/gbai
+ never have unused registers
+ no need for a register allocator
This is simplified. We'd need a register allocator for temporary
variables. But it's true that all the register allocation troubles we
now have with l
tions and register allocation cannot coexist. The solution is
to do away with the register allocator, or to do away with continuations.
This can be done, perhaps by saying that certain functions won't be subject
to continuation snapshots or calls. Then register allocation can be done on
thos
gt; that. In the mean time, search the perl6-internals mailing list for
> continuations and register allocation. I'm sure you'll find it.
I would actually very much like to see this issue moved on. In the
hopes of getting everything up to speed quickly I will try and
summarize all of th
At 7:20 PM +0100 11/30/04, Thomas Seiler wrote:
At Tue 30 Nov 6:22pm, Dan Sugalski wrote:
Architecture changes aren't an option we're entertaining until after we're
functionally complete.
Just would like to ask a related question:
Is a change that invalidates an existing precompiled bytecode but
At Tue 30 Nov 6:22pm, Dan Sugalski wrote:
> Architecture changes aren't an option we're entertaining until after we're
> functionally complete.
Just would like to ask a related question:
Is a change that invalidates an existing precompiled bytecode but not
the source code of it
considered as an ar
At 5:30 PM +0100 11/30/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
Below inline/attached are some thoughts WRT the subject.
leo
Lexicals, continuations, and register allocation
1) Recent discussions have shown t
> >>
> >>leo
> >>
> >>
> >>Lexicals, continuations, and register allocation
> >>
> >>1) Recent discussions have shown that we obviously can't handle all
> >>the side effects of continuations correctly. Reusing preserved
> >
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
>>Below inline/attached are some thoughts WRT the subject.
>>
>>leo
>>
>>
>>Lexicals, continuations, and register allocation
>>
>>1) Recent discus
Dan~
On Tue, 30 Nov 2004 10:22:29 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
>
>
> >Below inline/attached are some thoughts WRT the subject.
> >
> >leo
> >
> >
> >Lexicals, cont
At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
Below inline/attached are some thoughts WRT the subject.
leo
Lexicals, continuations, and register allocation
1) Recent discussions have shown that we obviously can't handle all
the side effects of continuations correctly. Reusing preserved
Bill Coffman <[EMAIL PROTECTED]> wrote:
>> two possible interferences of different kinds, with additional coding
>> overhead ...
> ... What makes it a
> little complicated is how do these "ubiquetous" symbols interact with
> the non-ubuiquitous? Those arcs are needed for this.
Yes that's what
the time, except for such platform stuff. I test
on two platforms, 3 computers. Tests are currently not passing due to
obvious violations of the recent pdd03 changes.
t/op/gc_13.imc would still fail because of continuation and register
allocation, it's just using lexicals now.
> ... Then it must
Matt Fowles <[EMAIL PROTECTED]> wrote:
> On Wed, 24 Nov 2004 17:25:05 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> a = b + c + foo()
> I am not sure that they are as rare as you think.
Does it matter? They are no lexicals, you can't refetch them. So they
get a distinct storage. When f
On Wed, 2004-11-24 at 15:04 +, Nicholas Clark wrote:
> Quite a lot of us would just like parrot COMPLETE and CORRECT before
> starting to put a lot of effort into how fast it is.
I'd settle for it compiling (#32514). If not for the broken build, I'd
have poked at three or four small TODO ite
n only work for nested closures. If libraries are
> involved you are out of luck.
It was Larry Wall who suggested the pragma in the long thread,
"Continuations, basic blocks, loops and register allocation ".
Although his message is somewhat genaral, he indicates a prefernce for
pragma
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I can't. My dev machine's running gcc 2.95.4, and gcc throws lisp
> error messages compiling the switch core if I turn on optimizations.
I've checked in a hook in ops2c.pl that splits the switched core all 300
ops. If that works, we can provide some confi
Leo~
On Wed, 24 Nov 2004 17:25:05 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
> > Leo~
>
> > On Wed, 24 Nov 2004 16:42:31 +0100, Leopold Toetsch <[EMAIL PROTECTED]>
> > wrote:
> >> And as a side effect it will make Dan's evils subs compile, because
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> On Wed, 24 Nov 2004 16:42:31 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> And as a side effect it will make Dan's evils subs compile, because
>> long-lived lexicals already have their storage aka register. Only temps
>> need a register alloca
Leo~
On Wed, 24 Nov 2004 16:42:31 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> And as a side effect it will make Dan's evils subs compile, because
> long-lived lexicals already have their storage aka register. Only temps
> need a register allocated.
What happens to temps that need to cross
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 24, 2004 at 09:45:27AM -0500, Ken Fox wrote:
>>As long as an architecture change is on the
>> table, might as well make it a doozy.
> Quite a lot of us would just like parrot COMPLETE and CORRECT before
> starting to
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> I'm probably going to get shot for suggesting this, but if each interpreter
> has a count of the number of full continuations invoked (ie non-return
> continuations), then I think that we can know when we *haven't*.
Nobody gets shot - and - interesting
Ken Fox <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>+-+--+
>>| ctp | interpreter state|
>>+-+--+
>> |
>> ++
>>|
>> +--+-+---+--+
>> |
On Wed, Nov 24, 2004 at 09:45:27AM -0500, Ken Fox wrote:
>As long as an architecture change is on the
> table, might as well make it a doozy.
Quite a lot of us would just like parrot COMPLETE and CORRECT before
starting to put a lot of effort into how fast it is.
PLEASE c
Leopold Toetsch wrote:
+-+--+
| ctp | interpreter state|
+-+--+
|
++
|
+--+-+---+--+
| prev | ctx | lexicals | volatiles|
+-
On Wed, Nov 24, 2004 at 09:39:27AM +0100, Leopold Toetsch wrote:
> Bill Coffman wrote:
> >Another interesting thing about this problem is that these new CFG
> >edges are rarely, or at least with low probability, ever travelled.
>
> We just don't know it, rare or not doesn't matter.
I'm probably
n't support them.
BTW, I wonder if there are any research papers on the topic of register
allocation in presence of continuations. I just looked at Citeseer, but
a quick cursory search didn't come up with anything useful.
Miro
Bill Coffman wrote:
On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Keep in mind that you don't actually have to add all those CFG edges.
You already know precisely the effects of adding them. All
non-volatile symbols (those crossing subs that might make continuati
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> I've clearly stated that lexicals aka non-volatiles have distinct
>> registers.
> Thus for these large subs, won't this be a large overhead?
Why? It's actually less
On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
> > ... However, if a continuation restores registers to the data they
> > had when the continuation was taken, then all of the registers will
> > contain the things that exactly
On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> > Have we seen that this actually destroys us? Meaning, if we add the
> > extra CFG arcs, do we start spilling like mad? If not, this is much
> > ado about nothing.
>
> Please first have a lo
Leo~
On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
>
> > Won't your approach put every one of those things in its own register?
>
> I've clearly stated that lexicals aka non-volatiles have distinct
> registers.
Thus for t
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Won't your approach put every one of those things in its own register?
I've clearly stated that lexicals aka non-volatiles have distinct
registers.
> ... However, if a continuation restores registers to the data they
> had when the continuation was taken
Leo~
On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> > Have we seen that this actually destroys us? Meaning, if we add the
> > extra CFG arcs, do we start spilling like mad? If not, this is much
> > ado about nothing.
>
> Please first hav
Matt Fowles wrote:
Have we seen that this actually destroys us? Meaning, if we add the
extra CFG arcs, do we start spilling like mad? If not, this is much
ado about nothing.
Please first have a look at Dan's recent posting about Evil Sub. Then
estimate, how many subs may be called in 14000 basic
At 12:27 PM -0500 11/23/04, Dan Sugalski wrote:
At 9:17 AM -0800 11/23/04, Bill Coffman wrote:
Wait, I just thought of a huge change.
Dan, Does the patch you have implement Leo's U_NON_VOLATILE patch?
It was the patch originally attached to this ticket, over a stock
parrot from CVS. If there's som
Leo~
On Tue, 23 Nov 2004 21:15:33 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Below inline/attached are some thoughts WRT the subject.
>
> leo
>
>
> Lexicals, continuations, and register allocation
>
> 1) Recent discussions have shown that we obvious
Below inline/attached are some thoughts WRT the subject.
leo
Lexicals, continuations, and register allocation
1) Recent discussions have shown that we obviously can't handle all
the side effects of continuations correctly. Reusing preserved
(non-volatile) registers after a call isn't po
At 9:17 AM -0800 11/23/04, Bill Coffman wrote:
Wait, I just thought of a huge change.
Dan, Does the patch you have implement Leo's U_NON_VOLATILE patch?
It was the patch originally attached to this ticket, over a stock
parrot from CVS. If there's something else to try let me know -- I'm
all for i
Wait, I just thought of a huge change.
Dan, Does the patch you have implement Leo's U_NON_VOLATILE patch? If
so, that restricts from 32 to 16 registers, in various cases for
*non-volatile* symbols (did I get that right?). Anyway, the symbols
that cross sub calls can only use 16 registers, where
At 5:40 PM +0100 11/23/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
I can't. My dev machine's running gcc 2.95.4, and gcc throws lisp
error messages compiling the switch core if I turn on optimizations.
You could try:
- perl Configure.pl --optimize
- make -s
- wait a bit unt
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I can't. My dev machine's running gcc 2.95.4, and gcc throws lisp
> error messages compiling the switch core if I turn on optimizations.
You could try:
- perl Configure.pl --optimize
- make -s
- wait a bit until first files start compiling
- interrupt it
At 8:25 AM -0800 11/23/04, Bill Coffman wrote:
On Tue, 23 Nov 2004 09:27:12 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
The parrot I have, which is a day or two out of date, takes 7m to
churn through one of my pir files. With this patch, I killed the run
at 19.5 minutes.
I'd be interested in
On Tue, 23 Nov 2004 09:27:12 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The parrot I have, which is a day or two out of date, takes 7m to
> churn through one of my pir files. With this patch, I killed the run
> at 19.5 minutes.
I'd be interested in getting this code for testing. The big one
At 4:02 PM +0100 11/23/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to
churn through one of my pir files. With this patch, I killed the
run at 19.5 minutes.
One more note: be sure to compile Parrot optimized - the new
reg_alloc.c h
At 3:54 PM +0100 11/23/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to
churn through one of my pir files. With this patch, I killed the
run at 19.5 minutes.
Sh... That's one of the smaller ones I presume.
Nope, one of the biggest. S
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to churn
through one of my pir files. With this patch, I killed the run at 19.5
minutes.
One more note: be sure to compile Parrot optimized - the new reg_alloc.c
has some very expensive sanity checks in debug mode
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to churn
through one of my pir files. With this patch, I killed the run at 19.5
minutes.
Sh... That's one of the smaller ones I presume. How many basic blocks
and variables are listed with -v?
Thanks,
leo
At 11:35 AM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
Okay. I'll apply it and take a shot. May take a few hours to get a
real number.
How does it look like? Any results already?
Okay, got some time this morning. Two of the patch hunks were already
in, so I skipped 'em. The result
At 11:35 AM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
Okay. I'll apply it and take a shot. May take a few hours to get a
real number.
How does it look like? Any results already?
Nope, haven't had time, unfortunately. Work's been busy. Today, if I get
lucky.
--
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
Dan Sugalski wrote:
Okay. I'll apply it and take a shot. May take a few hours to get a real
number.
How does it look like? Any results already?
Thanks,
leo
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
1 - 100 of 222 matches
Mail list logo
