At 7:36 PM -0500 3/3/03, Benjamin Goldberg wrote:
Dan Sugalski wrote:
Benjamin Goldberg wrote:
Jason Gloudon wrote:
Piers Cawley wrote:
I think you're overlooking the "restoreall" done just before
the jump-no-save-returnaddress operation... I see two "saveall"s
and two "restoreall"s.
But w
Benjamin Goldberg wrote:
Erm, my statement was actually just an assumption that the first op
would be a 'saveall' -- I haven't looked at actual imcc output.
imcc does not emit any additional instructions currently. This is why I
did start this thread in the first place.
- imcc takes the code
Dan Sugalski wrote:
> Benjamin Goldberg wrote:
>> Jason Gloudon wrote:
>>> Piers Cawley wrote:
>>>
> I think you're overlooking the "restoreall" done just before
> the jump-no-save-returnaddress operation... I see two "saveall"s
> and two "restoreall"s.
But with proper tail c
At 4:00 PM -0500 3/3/03, Benjamin Goldberg wrote:
Jason Gloudon wrote:
On Mon, Mar 03, 2003 at 01:07:36PM +, Piers Cawley wrote:
> > I think you're overlooking the "restoreall" done just before the
> > jump-no-save-returnaddress operation... I see two "saveall"s and
> > two "restoreall"s.
Jason Gloudon wrote:
>
> On Mon, Mar 03, 2003 at 01:07:36PM +, Piers Cawley wrote:
>
> > > I think you're overlooking the "restoreall" done just before the
> > > jump-no-save-returnaddress operation... I see two "saveall"s and
> > > two "restoreall"s.
> >
> > But with proper tail call optimi
On Mon, Mar 03, 2003 at 01:07:36PM +, Piers Cawley wrote:
> > I think you're overlooking the "restoreall" done just before the
> > jump-no-save-returnaddress operation... I see two "saveall"s and
> > two "restoreall"s.
>
> But with proper tail call optimization you'd only need *one*
> saveal
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
>> > Piers Cawley wrote:
>> > [snip]
>> >> Um... no. tail call optimization implies being able to replace *any*
>> >> tail call, not just a recursive one with a simple goto.
>> > [sn
At 6:57 PM -0500 2/27/03, Benjamin Goldberg wrote:
These are, for all intents and purposes, tail-call optimized versions of
the two functions you showed. True, this might not gain us much speed
in perl5, but it demonstrates the type of effect that I think that we're
aiming at, for parrot's tail-ca
Dan Sugalski wrote:
>
> At 10:03 PM -0500 2/26/03, Benjamin Goldberg wrote:
> >I would not have suggested such a thing. Tail call optomization in
> >parrot should be about the same logical semantics as perl5's goto
> >&subname (except maybe being faster).
>
> No it shouldn't. Tail call optimizat
At 10:03 PM -0500 2/26/03, Benjamin Goldberg wrote:
I would not have suggested such a thing. Tail call optomization in
parrot should be about the same logical semantics as perl5's goto
&subname (except maybe being faster).
No it shouldn't. Tail call optimization is far more useful in the case of:
Piers Cawley wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
>
> > Piers Cawley wrote:
> > [snip]
> >> Um... no. tail call optimization implies being able to replace *any*
> >> tail call, not just a recursive one with a simple goto.
> > [snip]
> >
> > In perl5, doing a tail call optimi
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
> [snip]
>> Um... no. tail call optimization implies being able to replace *any*
>> tail call, not just a recursive one with a simple goto.
> [snip]
>
> In perl5, doing a tail call optimization can be done with just a simple
> got
Piers Cawley wrote:
[snip]
> Um... no. tail call optimization implies being able to replace *any*
> tail call, not just a recursive one with a simple goto.
[snip]
In perl5, doing a tail call optimization can be done with just a simple
goto... well, 'goto &subname', anyway. (Well, first you'd assi
Jerome Vouillon <[EMAIL PROTECTED]> writes:
> On Tue, Feb 25, 2003 at 08:47:55AM +0100, Leopold Toetsch wrote:
>> >Um... no. tail call optimization implies being able to replace *any*
>> >tail call, not just a recursive one with a simple goto. Consider the
>> >following calling sequence:
>>
>>
>
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>
>> Steve Fink <[EMAIL PROTECTED]> writes:
>>
>>>... I didn't follow about how that interferes with tail-call
>>>optimization. (To me, "tail call optimization" == "replace recursive
>>>call with a goto to the end of the function pr
On Mon, Feb 24, 2003 at 05:29:26PM +, Piers Cawley wrote:
[Tail-call optimization]
> Under caller saves, this is easy to do. Under callee saves, b's second
> call to c() cannot simply return to Continuation A but must unwind the
> call stack via b to make sure that the right things are restored
On Tue, Feb 25, 2003 at 08:47:55AM +0100, Leopold Toetsch wrote:
> >Um... no. tail call optimization implies being able to replace *any*
> >tail call, not just a recursive one with a simple goto. Consider the
> >following calling sequence:
>
>
> > b(arg) -> Push Continuation A onto the continua
Piers Cawley wrote:
Steve Fink <[EMAIL PROTECTED]> writes:
... I didn't follow about how that interferes with tail-call
optimization. (To me, "tail call optimization" == "replace recursive
call with a goto to the end of the function preamble")
Um... no. tail call optimization implies being able t
Steve Fink <[EMAIL PROTECTED]> writes:
> I think this has been discussd before, but are we all okay with this
> callee-save-everything policy? At the very least, I'd be tempted to
> add a bitmasked saveall/restoreall pair to reduce the amount of cache
> thrashing. ("saveall 0b0010011000
Benjamin Goldberg wrote:
Dan Sugalski wrote:
Yeah, 32 is a bunch. I've considered going with 16 on and off, and
still might.
16 is not enough for non trivial subroutines. E.g. the _Generate sub in
life.p6 consumes 25 P regs.
Given that registers are allocated with the lower numbers being the
Dan Sugalski wrote:
>
> At 9:55 AM -0800 2/20/03, Steve Fink wrote:
[snip]
> >Or, as another stab at the same problem, does Parrot really need 32*4
> >registers? I keep thinking we might be better off with 16 of each
> >type. But maybe I'm just grumbling.
>
> Yeah, 32 is a bunch. I've considered
At 9:55 AM -0800 2/20/03, Steve Fink wrote:
I think this has been discussd before, but are we all okay with this
callee-save-everything policy?
Nope. It's safe to say that a lot of folks aren't. :)
Still, I think it's the right way to go in the general case. Most sub
calls of any complexity will
Steve Fink wrote:
On Feb-18, Leopold Toetsch wrote:
[ ... ]
.return mi# [1]
restoreall
ret
.end
My immediate reaction to this (okay, I really saw this before in
perl6-generated code) is "why don't the values from .return and
restoreall get mixed up?"
Yep. It is at least confu
On Thu, Feb 20, 2003 at 09:55:35AM -0800, Steve Fink wrote:
> I think this has been discussd before, but are we all okay with this
> callee-save-everything policy? At the very least, I'd be tempted to
> add a bitmasked saveall/restoreall pair to reduce the amount of cache
> thrashing. ("saveall 0b0
On Feb-18, Leopold Toetsch wrote:
> =head1 Stack calling conventions
>
> Arguments are Bd in reverse order onto the user stack:
>
>.arg y # save args in reversed order
>.arg x
>call _foo #(r, s) = _foo(x,y)
>.local int r
>.local int s
>.result s # restore results in
Attached is a pod
- describing the current existing stack calling convention
- proposing a syntax for parrot's NCI calling convention.
Comments ... welcome,
leo
=head1 NAME
IMCC - calling conventions
=head1 VERSION
=over 4
=item 0.1 intital proposal
=back
=head1 OVERVIEW
This document desc
26 matches
Mail list logo
