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 >