Thanks Dan. One little picky thing what is the naming convention for ops? find_method (currently in core.ops), call_method, and call_method_cc (or callcc_method?)
or findmeth, callmeth, and callmethcc (or callccmeth?) or findmethod, callmethod, and callmethodcc (or callccmethod?) Also, should the current 'invoke' op be changed to 'call'? I don't care exactly what the names are, but consistency is nice. Jonathan > -----Original Message----- > From: Dan Sugalski [mailto:[EMAIL PROTECTED] > > At 9:20 AM -0700 5/30/03, Jonathan Sillito wrote: > >Dan, > > > >Why is there a callmeth op? Can't we just use a regular invoke > as with other > >subs? Or does the callmeth op do both a find and invoke as an > optimization? > > It does a find and invoke, and the callmethcc does a find, > cc-capture, and invoke. > > I'm not sure if there'll be much win, but it is more information > available to analyzers, so they *know* that this is a method call > rather than a random sub call. > > I figure the vast majority of the method calls most languages make > will be either callmeth or callmethcc calls, so it makes sense to wad > up the functionality in a single op. > > > > -----Original Message----- > >> From: Dan Sugalski [mailto:[EMAIL PROTECTED] > >> > >> Nope, not objects, but at least it's partway there. This bit is about > >> making method calls. > >> > >> We've two issues on the front end. First, we need to be able to get a > >> method PMC from an object, in those cases where we want to save that > >> for later, and second we need to call methods. So, here's how we're > >> going to do it. > >> > >> We add three ops, findmeth, callmeth and callmethcc. (The latter just > >> automatically takes a continuation for the following op and stashes > >> it in P2, while the former assumes one has been put in P2 already) > >> They all find a method PMC based on the object and method name > >> already loaded. The call ops then call > >> that PMC's invoke vtable entry, which acts as normal. > >> > >> So the sequence is: > >> > >> P0 = P2->find_method(interpreter, P2); > >> > >> and for the call ops, then: > >> > >> dest = P0->invoke(interpreter, P0, expr NEXT()); > >> goto ADDRESS(dest); > >> > >> The returned method PMC handles anything fancy--multimethod dispatch > >> and whatnot. We need base engine support for MMD and method caching, > >> amongst other things, but we can get to that later. > >> > >> The method PMC returned by findmeth can be invoked as a regular > >> subroutine, so we're fine there. I'm not, at the moment, leaning > >> towards a separate "invoke this pre-fetched PMC sub as a method" op, > >> since we're not passing on any information as to how a PMC is invoked > >> outside of there being an object in P2, but I can be convinced > >> otherwise if we can make a good case for languages actually using > >> that information. > >> > >> I'm thinking at this point, since we need to add the call and callcc > >> ops as it is, that we should probably have tail versions of all these > >> ops, which just puts the various bits from the continuation in P1 > >> back before making the call, but we can talk about that later if we > >> want. > >> -- > >> Dan > >> > >> --------------------------------------"it's like > this"------------------- > >> Dan Sugalski even samurai > >> [EMAIL PROTECTED] have teddy bears and even > >> teddy bears get drunk > >> > > > -- > Dan > > --------------------------------------"it's like this"------------------- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk >
