Hey, thanks for the comments.
So you suggest leaving as the op as invoke? I don't mind, I just think we
should be consistent in our naming; what about having the following four
ops:
- invoke
- invokecc
- invoke_method
- invokecc_method
You also wondered about the need for the 'cc' variants of these ops. If
parrot's calling convention is to be continuation passing style then before
each invoke we need to set up a continuation (in P1). In the common case
this is just the "current continuation". In pasm this could be:
new P1, .Continuation
set_addr I3, returnhere
set P1, I3
invoke # or invoke_method
returnhere:
# etc ...
With a 'cc' variant the common case is simplified to be just:
invokecc # or invokecc_method
# etc ...
What do you think? Is it worth two more ops?
BTW does anyone (leo?, dan?) want to comment on my idea for getting rid of
the register stacks etc:
"calling convention and continuation ramblings"
http://xrl.us/iy8
Jonathan Sillito
> -----Original Message-----
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
>
> Jonathan Sillito <[EMAIL PROTECTED]> wrote:
>
> > 1. some adding and renaming in core.ops, which gives the following ops:
> > - call()
> > - call(in PMC)
>
> Suboptimal. We will get a name clash in imcc. (Imcc has call as an alias
> for bsr)
>
>
> > 2. adds pmc access macros to register.h (as suggested by Mitchell).
>
> Thats fine.
>
> > 3. updates tests, examples and documentation to use call
> instead of invoke.
> > still to do:
> > - update language/imcc to use call instead of invoke??
>
> This - if ever - can only be done in one big change in parrot and imcc.
>
> But I don't know, why we actually should s/invoke/call/. bsr/call is
> similar to a hardware CPU subroutine call, so I think, it should remain
> call (in imcc). invoke is a higher level construct and therfore deserves
> its special name.
>
> > - add callcc and callcc_method - patch coming soon
>
> Why do we need another 2 ops? invoke on the appropriate class should be
> enough.
>
> leo
>
