[pypy-dev] Avoiding code duplication
Antonio Cuni
anto.cuni at gmail.com
Mon Apr 17 14:45:15 CEST 2006
Hi Armin, hi all
Armin Rigo wrote:
> A different comment: as you mentioned on IRC it would be nice if the
> back-end could choose which methods it implements natively. At one
> point there was the idea that maybe the 'oopspec' attributes that
> started to show up in lltypesystem/rlist.py (used by the JIT only) could
> be useful in this respect. If I remember correctly, the idea didn't
> work out because of the different 'lowleveltype' needed, and the
> difference in the interface. Merging the ADT method names of lltyped
> lists and the GENERIC_METHODS of ootyped lists could be a step in this
> direction again. The interesting point is that each oo back-end could
> then choose to special-case the ll_xxx() functions with the oopspecs
> that they recognize, and just translate the other ones normally. (The
> ll back-ends always translate them all.)
I have successfully moved almost all ll_* helpers from
rpython/lltypesystem/rlist.py to rpython/rlist.py so that now they are
shared between the two typesystems.
For doing that I had to extend the ADT interface of ListRepr to include
_ll_resize_ge and _ll_resize_le, as well as to add the same function as
_GENERIC_METHODS in ootypesystem.
Now ootypesystem should support the full list's semantic but in a
far-from-perfect way: the main issue is that most operations are done by
the ll_* helpers, even when there could be a more efficient native
equivalent.
I see three main ways of fixing that:
1) further extend the ADT/_GENERIC_METHODS interface to include common
operations that could be natively available in OO targets and modify
ll_* helpers to use that methods; e.g., we could insert a "remove_range"
and let ll_listdelslice & co. using it. This way OO backends could
easily forward call to remove_range to the runtime; moreover if the
inliner works well there should be no performance penalties for
lltypesystem;
2) follow Armin's suggestion to use oopspec for letting backends
forwarding to the RTE only what they want;
3) a mixture of 1 and 2.
ciao Anto
More information about the Pypy-dev
mailing list