Making tail calls/invoking continuations
Piers Cawley
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 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 detect tail calls and automatically optimize
them is a no no too, but it'd be very handy if there were some sugar to
allow me to specify that it's a tail call (or a continuation
invokation). How plausible is:
foo(...), nosave
or
foo(...) nosave
AFAICT the grammar should be able accommodate such changes to the
syntax.
Thoughts?
Leopold Toetsch
> 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
> .pcc_end
> But, looking at the PASM generated by 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.
Yep. The C<updatecc> 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<savetop> is from the normal calling sequence.
> ... As Dan's pointed
> out on IRC, having IMCC detect tail calls and automatically optimize
> them is a no no too,
Why?
> ... but it'd be very handy if there were some sugar to
> allow me to specify that it's a tail call (or a continuation
> invokation). How plausible is:
> foo(...), nosave
What about these low-leval directives:
.tail_call sub # .pcc_call
.tail_meth_call sub # .meth_call
and:
foo() tail_call
obj."meth"() tail_call
leo