William Coleda [EMAIL PROTECTED] wrote:
Is it sufficient to provide a mechanism for the compiler writers to indicate
that tail call should be used? For example, I have a few cases in tcl where I
have something like:
($I0,$P0) = interpret($P1)
.return($I0,$P0)
Where I'd be happy to
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 10, 2004, at 3:08 PM, Leopold Toetsch wrote:
But, in a tail-call-optimization case, we don't need to call
new_register_frame() and copy_regs()--ex hypothesi, we can re-use the
register frame already in-place. That's a big savings--that's the
On Nov 10, 2004, at 11:53 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
...it sounds like we have an easy way to tell if a real continuation
has a claim on the register frame, because creating such a real
continuation can mark the frame,
There is no such mark. If ctx-current_cont
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 10, 2004, at 11:53 PM, Leopold Toetsch wrote:
[ refcounting continuations ]
That's really not needed. If you return from the function and you call
it next time, you've again a RetContinuation. If the continuation was
created somewhere deeper in
Jeff Clites [EMAIL PROTECTED] wrote:
I was thinking: Implementing tail calls seems easy;
I thought that too. So I did it ;)
$ time parrot -j fact.imc 1 # [1]
maximum recursion depth exceeded
$ time parrot -Oc -j fact.imc 1 2# [2]
real0m0.635s
$ time
At 1:24 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 10, 2004, at 11:53 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
This OTOH is meaning that we can do the
check only at runtime. Thus the Ctailcall or Ctailcallmethod opcodes
have to do plain calls if they detect such a
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things, and
I think that's just not worth the risk and hassle. Besides, it's a
lot easier in
Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things,
Yep. So is it implemented:
* tailcall / tailcallmethod opcodes
* the former is currently created by imcc with parrot -Oc
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things
Nah, that's just the difference between
At 7:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things,
Yep. So is it implemented:
* tailcall / tailcallmethod opcodes
* the
of this, but continuations shouldn't
affect tail calls at all. There's certainly no reason they ought to.
All a tail call does is use the current return continuation as the
return continuation for the call you're making. That's not affected
by taking a continuation.
If this is from some side
just can't immediately re-use the register
frame. That satisfies the Scheme requirement, I would think. You can
still do unbounded recursion, just that GC may need to run to clean
up call frames.
I only skimmed the earlier parts of this, but continuations shouldn't
affect tail calls at all.
You
shouldn't affect tail calls at all.
You should read the thread then.
Joy. That means continuations are broken still.
If this is from some side effect of call speed optimization (I
remember seeing some discussion of stack allocation of call frames
or something, but I don't recall if it was before
Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:54 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 11:24 AM, Dan Sugalski wrote:
I only skimmed the earlier parts of this, but continuations
shouldn't affect tail calls at all.
You should read the thread then.
Joy. That means continuations
Dan Sugalski [EMAIL PROTECTED] wrote:
At 7:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Patch is probably ready tomorrow.
Cool. I think I'd like to skip having to specify the -Oc flag,
though, and add explicit syntax to PIR.
Do we really need it? Are there wicked cases, where we could
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Tail calls should be explicit, compile-time things.
Nah, that's just the difference between running optimized and
unoptimized.
At 10:13 PM +0100 11/11/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 7:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Patch is probably ready tomorrow.
Cool. I think I'd like to skip having to specify the -Oc flag,
though, and add explicit syntax to PIR.
Do we really need
On Thu, 11 Nov 2004 21:59:06 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Above is *without* tail calls. The next one was with tail calls, and it
obviously did succeed, because tail calls do not contribute to any kind
of stack depth. So there is for sure no limit. It's the same as an
At 10:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:54 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 11:24 AM, Dan Sugalski wrote:
I only skimmed the earlier parts of this, but continuations
shouldn't affect tail calls at all.
You should
On Nov 11, 2004, at 12:59 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I think that actually doesn't matter. Even in the case where we think
we can't do a full tail call optimization (because of a continuation
that's been taken), we can still actually remove the calling frame
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 11, 2004, at 12:59 PM, Leopold Toetsch wrote:
As Dan already has outlined a Continuation doesn't have any impact on
tail calls (my argument WRT that was wrong)
I'm confused then. What from the previous discussion in this thread was
incorrect?
We
, but allows less actual tail calls).
Do any existing languages have both tail calls and continuations?
Scheme mandates that anything which looks like a tail call, must be
optimized as expected (other languages like Lisp merely permit it), but
I don't know of Scheme having continuations. Scheme cares
Scheme is a counterexample, it supports both mandatory tail calls
continuations.
I've no idea how stuff is implemented in Parrot, but an obvious idea
would be to have some kind of lazy copying scheme (i.e. maintain a
reference count for the stack frames copy the respective one before
mutating
Jeff~
On Wed, 10 Nov 2004 10:40:45 -0800, Jeff Clites [EMAIL PROTECTED] wrote:
I was thinking: Implementing tail calls seems easy; the normal calling
sequence of do some setup, then jump just turns into don't bother
with (most of) the setup, just jump. That is, don't move a new
register
Jeff Clites [EMAIL PROTECTED] wrote:
But there's one wiggle: If you've created a continuation previously
(and it still exists), then any call has to preserve the frame
Well, that's what continuations are doing. They do preserve the frame,
which they have taken a snapshot of. And they preserve
Is it sufficient to provide a mechanism for the compiler writers to indicate
that tail call should be used? For example, I have a few cases in tcl where I
have something like:
($I0,$P0) = interpret($P1)
.return($I0,$P0)
Where I'd be happy to have to write:
.return_tailcall(interpret($P1))
or
On Nov 10, 2004, at 3:08 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
But there's one wiggle: If you've created a continuation previously
(and it still exists), then any call has to preserve the frame
Well, that's what continuations are doing. They do preserve the frame,
which
Is there any syntactic sugar in IMCC for making a tail call? Right
now, AFAICT, the trick is to do:
.pcc_begin
.arg Foo
.arg bar
.pcc_call sub, P1 # Or whatever the syntax is to get
# the current continuation
.pcc_end
But, looking at the PASM generated by
Piers Cawley [EMAIL PROTECTED] wrote:
Is there any syntactic sugar in IMCC for making a tail call?
No.
Right now, AFAICT, the trick is to do:
.pcc_begin
.arg Foo
.arg bar
.pcc_call sub, P1 # Or whatever the syntax is to get
# the current continuation
29 matches
Mail list logo
