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
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
