On Feb-22, Dan Sugalski wrote: > At 10:20 AM -0800 2/20/03, Steve Fink wrote: > >The invoke op is bothering me -- namely, it disturbs me that it > >implicitly operates on P0. I know that P0 is the correct register to > >use according to pdd03, but I dislike having it be implicit. The user > >is required to set the rest of the pdd03 conventions up manually, so I > >don't see any need for invoke to be different. > > It isn't, though. You have to set up P0 just like all the other > registers you're using. It's not like invoke makes you specify them > either. (Though I could certainly see a case for a version that takes > counts as parameters and sets up the I registers appropriately, for > speed reasons)
I suppose that's true, if you really are doing full externally-visible (pdd03-compliant) invoke() calls. But if you're doing internal stuff, then it starts to matter what things are part of the invoke() interface, and what things are purely (calling) convention. At the moment, Sub.pmc's invoke() really only looks at P0. Will it eventually use all of pdd03's registers, or will some of that always be handled by the callee? I don't really know the fundamental motivation underlying 'invoke', so I can't guess the answer to this. I suppose if invoke is going to be used for multiple dispatch, then it really will use everything -- register counts, return type, the actual parameters, etc. > I'm OK with a one-arg version, as long as it's made explicit in the > docs that code that uses it makes no guarantees about the state of > any of the registers. > -- I'll need the answer to the previous question before I can write those docs.
