[Python-Dev] Python Call Mechanism
Wed, 01 Nov 2000 21:31:08 +0100
Michael Hudson wrote:
> Jeremy Hylton <firstname.lastname@example.org> writes:
> > >>>>> "MAL" == M -A Lemburg <email@example.com> writes:
> > MAL> Jeremy Hylton wrote:
> > >>
> > >> Update of /cvsroot/python/python/dist/src/Python In directory
> > >> slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python
> > >>
> > >> Modified Files: ceval.c ... N.B. The CALL_FUNCTION
> > >> implementation is getting really hairy; should review it to see
> > >> if it can be simplified.
> > MAL> How about a complete redesign of the whole call mechanism ?!
> > I'd be interested in looking at it.
> Random idea that occurred while answering a post on comp.lang.python:
> How about dumping the CALL_FUNCTION* opcodes, and replacing them with
> two non-argumented opcodes, called for the sake of argument NCALL_FUNC
> and NCALL_FUNC_KW.
> NCALL_FUNC would pop a function object and a tuple off the stack and
> apply the function to the tuple.
> NCALL_FUNC_KW would do the same, then pop a dictionary and then do
> the moral equivalent of f(*args,**kw).
> As a preliminary it would be sensible to rework BUILD_MAP so that it
> built dictionaries off the stack (a bit like BUILD_LIST, and like
> CALL_FUNCTION now does with keyword arguments...) (and extend the
> compiler to use this for literal dictionaries).
> This would add an opcode or so per function call, but would probably
> make life much simpler.
> No time for implementation tonight, but could probably knock something
> up tomorrow (depending how hard it turns out to be).
> Thoughts? Is that like what you did, Marc?
No, I just cleaned up the intertwine calling scheme currently
implemented in ceval.c. This allows a few improvments, one of
them being the possibility to inline C function calls in the
main loop (anyone ever trace the path Python takes when calling
a builtin function or method... you'd be surprised).
About your idea with the new opcodes: you could be touching
a performance relevant section there -- a ceval round-trip
may cost more than the added if()s in the CALL_FUNCION opcode.
Python Pages: http://www.lemburg.com/python/