wlavrij...@lbl.gov, 10.07.2012 20:10: >> There's no reason it would require wrapped arguments. > > that completely depends on how it is generated, of course, and in the context > of calls within Python (pypy-c), it makes sense to have the entry point of > the function expect wrapped arguments, and have the exit point re-wrap.
There's no reason you can't have multiple entry points to the same code. Cython has been doing this for a while, and I'm sure PyPy's JIT does it, too. >> The input types are >> known from the static low-level function type, so the JIT compiler can just >> work with them and adapt the function that is being called. > > Yes, except that the above only follows after this: > >> These things are trickier in a non-JIT environment, but we are currently >> working on a general framework to support low-level calls through the >> CPython ecosystem (I mentioned that before). > > I.e., there should first be a good method of delivering the low-level info. Sure, that's why we've been working on a specification for a protocol here. Basically, the caller and the callee would have to agree on a common signature at runtime out of the given N:M set of choices. A JIT compiler would obviously prefer generating a suitable signature, given the set of signatures that the other side presents. > Right now, that delivery method is the act of unwrapping itself (that is, > the wrapped types carry the low-level info). I have no idea what you mean, but you make it sound backwards for the case of a callback. Stefan _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
