-The RPython Typer lives in the directory `
+The RPython Typer lives in the directory `rpython/`_.
where -- in C notation -- all three variables v1, v2 and v3 are typed ``int``.
This is done by attaching an attribute ``concretetype`` to v1, v2 and v3
(which might be instances of Variable or possibly Constant). In our model,
-this ``concretetype`` is ``
+this ``concretetype`` is ``rpython.lltypesystem.lltype.Signed``. Of
course, the purpose of replacing the operation called ``add`` with
``int_add`` is that code generators no longer have to worry about what kind
of addition (or concatenation maybe?) it means.
each operation. In both cases the analysis of an operation depends on the
annotations of its input arguments. This is reflected in the usage of the same
``__extend__`` syntax in the source files (compare e.g.
`pypy/annotat ion/binaryop.py`_ and ` pypy/rpython/rint.py`_).
+/annotat/binaryop.py`_ and `rpython/rint.py`_).
The analogy stops here, though: while it runs, the Annotator is in the middle
of computing the annotations, so it might need to reflow and generalize until
implementations for the same high-level operations. This is the reason for
turning representations into explicit objects.
-The base Repr class is defined in `
pypy/rpython/rmodel.py`_. Most of the
+The base Repr class is defined in `rpython/rmodel.py`_. Most of the
``rpython/r*.py`` files define one or a few subclasses of Repr. The method
getrepr() of the RTyper will build and cache a single Repr instance per
SomeXxx() instance; moreover, two SomeXxx() instances that are equal get the
The RPython Typer uses a standard low-level model which we believe can
correspond rather directly to various target languages such as C.
This model is implemented in the first part of
-The second part of `
pypy/rpython/lltypesystem/lltype.py`_ is a runnable
+The second part of `rpython/lltypesystem/lltype.py`_ is a runnable
implementation of these types, for testing purposes. It allows us to write
and test plain Python code using a malloc() function to obtain and manipulate
structures and arrays. This is useful for example to implement and test
- >>> from
pypy.rpython.lltypesystem.lltype import *
+ >>> from rpython.lltypesystem.lltype import *
Here are a few primitive low-level types, and the typeOf() function to figure
types like list in this elementary world. The ``malloc()`` function is a kind
of placeholder, which must eventually be provided by the code generator for the
target platform; but as we have just seen its Python implementation in
`pypy/rpython/lltypesystem/lltype.py`_ works too, which is primarily useful for
+/lltypesystem/lltype.py`_ works too, which is primarily useful for
testing, interactive exploring, etc.
The argument to ``malloc()`` is the structure type directly, but it returns a
Structure types are built as instances of
MyStructType = Struct('somename', ('field1', Type1), ('field2', Type2)...)
MyStructType = GcStruct('somename', ('field1', Type1), ('field2', Type2)...)
An array type is built as an instance of
MyIntArray = Array(Signed)
MyOtherArray = Array(MyItemType)
with care: the bigger structure of which they are part of could be freed while
the Ptr to the substructure is still in use. In general, it is a good idea to
avoid passing around pointers to inlined substructures of malloc()ed structures.
-(The testing implementation of `
pypy/rpython/lltypesystem/lltype.py`_ checks to some
+(The testing implementation of `rpython/lltypesystem/lltype.py`_ checks to some
extent that you are not trying to use a pointer to a structure after its
container has been freed, using weak references. But pointers to non-GC
structures are not officially meant to be weak references: using them after what
change needed to the Annotator to allow it to perform type inference of our
very-low-level snippets of code.
-See for example `
+See for example `rpython/rlist.py`_.
targeting low level backends such as C, but it is not good
enough for targeting higher level backends such as .NET CLI or Java
JVM, so a new object oriented model has been introduced. This model is
-implemented in the first part of `
+implemented in the first part of `rpython/ootypesystem/ootype.py`_.
As for the low-level typesystem, the second part of
`pypy/rpython/ootypesystem/ootype.py`_ is a runnable implementation of
+/ootypesystem/ootype.py`_ is a runnable implementation of
these types, for testing purposes.
The LLInterpreter is a simple piece of code that is able to interpret flow
graphs. This is very useful for testing purposes, especially if you work on
the RPython Typer. The most useful interface for it is the ``interpret``
-function in the file `
pypy/rpython/test/test_llinterp.py`_. It takes as
+function in the file `rpython/test/test_llinterp.py`_. It takes as
arguments a function and a list of arguments with which the function is
supposed to be called. Then it generates the flow graph, annotates it
according to the types of the arguments you passed to it and runs the