Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
The common cases I want to optimize for are common functions being called as common functions. And common methods being called as methods.
Yep, that's very reasonable.
The easiest way to optimize for the common methods being called as methods is if the current object is not passed as the first argument.
Why so? Python methods don't have a notion of an object - it's just the first argument passed into a function. So I don't quite understand your conclusion.
In the case of
x.y(z)
The caller is passing one argument. The recipient is expecting two. The recipient defines what is expected as the first argument (in class methods it is the class, in instance methods it is the instance).
So, in the general case, the callee is responsible for inserting a parameter at the beginning of the PMC parameters. Insertion by setting a value into P2 is cheaper than insertion by shifting and then setting a value into P5.
Yes, copying will be required in cases where functions are called as methods.
How do you detect this case and when are arguments shifted then - note: I prefer the term shifting as copying is done anyway in all sub calls (see src/sub.c:copy_regs).
I agree that shifting is a more appropriate term.
At definition time, the PyFunc PMC has a number of properties (or flags) which are set defining names of the formal arguments, defaults, and the like. A similar approach can be used to define whether the first parameter is expected in P2 or P5. Note: this is not yet implemented for Python on Parrot.
Note: different languages may chose different strategies as to when to shift. What is important is that we come to an agreement on what is expected of the caller.
- Sam Ruby
