[pypy-dev] Rethinking genc with graph rewriting

[Armin Rigo]

PS.

I realize my previous e-mail carried a high risk of confusion.  In there,
W_ListObject was used as an example of RPython code; it was just an example,
unrelated to the fact that the example discusses how to implement lists like
the W_ListObject.ob_item field.  I could have chosen W_TupleObject or
W_DictObject as the example, and it would still have been about how to
implement their fields that are RPython lists (e.g. W_TupleObject.wrappeditems
or W_DictObject.data).

In the particular example of W_ListObject, we would like (it is our goal) that
the W_ListObject class be translated into a C structure with three fields that
look like "size", "allocated" and "items_ptr".  We want this because it is the
best C-ish version of the W_ListObject class, among less efficient variants
incurring more indirections; CPython uses this most efficient variant too in
its C structure called PyListObject.

This is not to be confused with lists as understood by RPython.  The field
W_ListObject.ob_item is such a list.  They are marked with a SomeList()
annotation.  The RPython-to-C translator needs to know precisely what such
lists are, and how to turn them into C code.  We decided earlier that such
lists would be translated as some sort of simple C array with no
over-allocation, so that they look like a pointer to a structure with a
"length" and an "items_ptr" field.  This, the translator knows.  It is so with
any usage of lists in RPython code, not just in W_ListObject.

So the goal in the example was how to have the translator automatically turn a
class like W_ListObject into a C structure that would have fields that look
like "size", "allocated" and "items_ptr", and doing so using the knowledge
that W_ListObject has two fields, ob_size and ob_item, with annotations
SomeInteger() and SomeList() respectively.


A bientôt,

Armin.