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
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 savealls
and two restorealls.
But with
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.
[snip]
In perl5, doing
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 savealls and
two restorealls.
But with proper tail call optimization you'd only need *one*
saveall. That's why
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 savealls and
two restorealls.
But with proper tail call optimization you'd only
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 savealls and
two restorealls.
But
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 savealls
and two restorealls.
But with proper tail call optimization you'd only need
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:
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 optimization is far
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
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 optimization can be done
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 continuation chain
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.
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 preamble)
Um... no.
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:
b(arg) -
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 assign
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
goto... well,
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
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 to
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
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
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
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
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 going
On Feb-18, Leopold Toetsch wrote:
=head1 Stack calling conventions
Arguments are Bsaved 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
26 matches
Mail list logo
