7, The Perl Foundation.
+# Copyright (C) 2001-2008, The Perl Foundation.
# $Id$
use strict;
@@ -7,7 +7,7 @@
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test tests => 97;
+use Parrot::Test tests => 98;
=head1 NAME
@@ -2489,6 +2489,37 @@
/too many argument
On 5/7/07, Bram Geron <[EMAIL PROTECTED]> wrote:
Alek, I made the bulk of the patch before I dug through the other mails
and saw your mail. I'm sorry if you were still planning on sending it.
Don't feel sorry at all. I got halfway through the patch before I got
distracted by other things.
to it. All further tailcalled contexts
> are freed as normal. That's pretty vague, but it's easier just to see the
> code. I just haven't had time to finish and release it.
>
> Thanks,
> Alek Storm
>
> On 3/4/07, Jonathan Worthington <[EMAIL PROTECTED]> wrot
se it.
Thanks,
Alek Storm
On 3/4/07, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
Bram Geron (via RT) wrote:
> Tail calls from within v-table methods are broken, the tail-called sub
> (or method) will not return correct values.
>
> When method A tailcalls sub B, B's
Bram Geron (via RT) wrote:
Tail calls from within v-table methods are broken, the tail-called sub
(or method) will not return correct values.
When method A tailcalls sub B, B's set_returns stores its opcode
number (and with it, which registers should be returned), but the
low-level vtable
cc
---
Flags:
category=core
severity=medium
ack=no
---
Tail calls from within v-table methods are broken, the tail-called sub
(or method) will not return correct values.
When method A tailcalls sub B, B's set_returns stores its opcode
number (and with it, which registers should be return
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 prev
ove the calling frame
from
the call stack--we just can't immediately re-use the register frame.
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?
JEff
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.
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&#
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 nee
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 di
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
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.
>>
>
ly 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 are broken still.
If this is from some side effect of call speed optimization (I
remember seeing some discussion of stack allocation of call fram
lling frame
from the call stack--we 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
At 11:16 AM -0800 11/11/04, Jeff Clites 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. Otherwise we're
going to run afoul of traceback requi
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 op
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 jus
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
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 hass
though there will be some situations where we can know for
sure at compile time--for instance if all function calls within a
function are tail calls.
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things, and
I t
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]
real
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 deep
ns where we can know for sure
at compile time--for instance if all function calls within a function
are tail calls. (We could have a special sort of C,
but that depends on our philosophy--if it's okay for the VM to trust
the compiler. Or possibly the VM could detect this, and cache this
inf
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
>
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 happ
hasn't also captured the context.
But in light of what you say here...
The concept of a return continuation (which recycles itself and the
frame it returned from) doesn't have an influence on tail calls.
Whenever you see a continuation "on the surface", it's one that is
preservi
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 s
ken a snapshot of. And they preserve any frames up the
call chain. This is needed and implemented and working.
The concept of a return continuation (which recycles itself and the
frame it returned from) doesn't have an influence on tail calls.
Whenever you see a continuation "on the surface&quo
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, ju
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 be
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 base-pointer into place, etc.
But there
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #31681]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31681 >
Most of the support's in, we just need to finish it. We just need to
get the tailcal
th of which are utterly unnecessary for a tail call.
Yep. The C is there to get any context changes between
construction of P1 and the call into the context: e.g.
newcont P1, .Continuation, foo
...
warningson 1
.pcc_call sub, P1
C is from the normal calling sequence.
> ... As Dan&#
pcc_4.imc (which is where I
picked this up from) that doesn't seem to actually have any benefit
because the resulting code still does a 'savetop' and an 'updatecc',
both of which are utterly unnecessary for a tail call. As Dan's pointed
out on IRC, having IMCC detec
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> If the subroutine is passed in, a runtime check could be done:
>>
>> if sub.isa("Sub") goto do_jump
>> invoke
> Umm... not sure quite what you mean there. Don't forget that the sub
> could be got by doing
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>
>> I'm not sure you can optimize it to a jump opcode when you're tail
>> calling another function can you? You could be tailcalling into a
>> closure so you'll need to use invoke to do the right thing with the
Piers Cawley <[EMAIL PROTECTED]> wrote:
> I'm not sure you can optimize it to a jump opcode when you're tail
> calling another function can you? You could be tailcalling into a
> closure so you'll need to use invoke to do the right thing with the
> lexical stack etc.
Argh, yes. What about:
If th
he class
> > and can decide at compile time to either jump or invoke.
> >
> > If the subroutine is passed in, a runtime check could be done:
> >
> > if sub.isa("Sub") goto do_jump
> > invoke
>
> Umm... not sure quite what you mean there. Don'
40 matches
Mail list logo
