I have a working implementation that that switches parrot to a continuation
passing style. While working on cleaning up a few things up, I got the
following idea ...
The current parrot context struct has a set of register stacks
struct IRegChunk *int_reg_top;
struct NRegChunk *num_reg_top;
etc ...
These are used when saving and restoring the registers. Are they used other
than when following the (old) calling convention? I would like to get rid of
these register stacks. In their place I would like to introduce a context
object (call it a continuation?) that saves and restores the stacks
(user_stack, pad_stack, control_stack, and intstack) and the last half of
the registers: P16-P31, I16-I31, etc. (These registers are not involved in
the calling or returning convention.) This would make it unnecessary to put
a saveall and a restoreall around each call/callcc. Of course it would still
be possible to save and restore individual registers on the user stack.
Calling a subroutine would look like (note: no saveall/restoreall needed)
set P0, ... # put Sub PMC in place
callcc # creates a context object
# invokes the sub in P0
or for tail calls and other fancy stuff
set P0, ... # put Sub PMC in place
set P1, ... # put some context in P1 (unless it
# is already in place as it would
# be for most tail calls)
call # invokes the sub in P0, the current
# context is not saved
returning looks like
sub:
# put return values in registers ...
return # invokes context in P1, which
# restores context etc
or even just
sub:
# put return values in registers ...
call P1 # same as return
Just to be clear my current implementation does most of this, except that
none of the registers are saved as part of the context, just the stacks
(including the register stacks). So my proposal is to get rid of the
register stacks and have the context object save (and restore) *half* of the
registers in addition to the user, pad, control and int stacks.
This seems like a nice approach to me as it simplifies the Parrot_Context
struct and the calling and returning from subs and methods.
Comments?
--
Jonathan Sillito
