[pypy-svn] r41519 - pypy/dist/pypy/doc
arigo at codespeak.net
arigo at codespeak.net
Tue Mar 27 18:09:42 CEST 2007
Author: arigo
Date: Tue Mar 27 18:09:41 2007
New Revision: 41519
Modified:
pypy/dist/pypy/doc/faq.txt
pypy/dist/pypy/doc/new-architecture.txt
Log:
Finished my review of new-architecture.txt.
Modified: pypy/dist/pypy/doc/faq.txt
==============================================================================
--- pypy/dist/pypy/doc/faq.txt (original)
+++ pypy/dist/pypy/doc/faq.txt Tue Mar 27 18:09:41 2007
@@ -138,6 +138,7 @@
.. _`rctypes`: rctypes.html
.. _`slower than CPython`:
+.. _`how fast is pypy`:
-----------------
How fast is PyPy?
Modified: pypy/dist/pypy/doc/new-architecture.txt
==============================================================================
--- pypy/dist/pypy/doc/new-architecture.txt (original)
+++ pypy/dist/pypy/doc/new-architecture.txt Tue Mar 27 18:09:41 2007
@@ -36,7 +36,7 @@
High Level Goals
=============================
-PyPy - The Translation Framework
+PyPy - the Translation Framework
-----------------------------------------------
Traditionally, language interpreters are written in a target platform language
@@ -88,19 +88,23 @@
--------------------------------------------
Our main motivation for developing the translation framework is to
-provide a full featured, customizable and fast Python implementation,
-working on and interacting with a large variety of platforms and
-allowing the quick introduction of new advanced language features.
+provide a full featured, customizable, fast_ and `very compliant`_ Python
+implementation, working on and interacting with a large variety of
+platforms and allowing the quick introduction of new advanced language
+features.
This Python implementation is written in RPython as a relatively simple
interpreter, in some respects easier to understand than CPython, the C
reference implementation of Python. We are using its high level and
flexibility to quickly experiment with features or implementation
techniques in ways that would, in a traditional approach, require
-pervasive changes to the source code. The archetypical example is
-reference counting in CPython: changing it to use another garbage
-collector would be a major undertaking, whereas in PyPy it is an issue
-orthogonal to the interpreter source code.
+pervasive changes to the source code. For example, PyPy's Python
+interpreter can optionally provide lazily computed objects - a small
+extension that would require global changes in CPython. Another example
+is the garbage collection technique: changing CPython to use a garbage
+collector not based on reference counting would be a major undertaking,
+whereas in PyPy it is an issue localized in the translation framework,
+and fully orthogonal to the interpreter source code.
PyPy Architecture
@@ -109,9 +113,62 @@
As you would expect from a project implemented using ideas from the world
of `Extreme Programming`_, the architecture of PyPy has evolved over time
and continues to evolve. Nevertheless, the high level architecture is
-stable. There are two rather independent basic subsystems: the `Python
-Interpreter`_ and `the Translation Framework`_. We first talk about the
-Python Interpreter because of its re-use by the Translation framework.
+stable. As described above, there are two rather independent basic
+subsystems: the `Python Interpreter`_ and the `Translation Framework`_.
+
+.. _`translation framework`:
+
+The Translation Framework
+-------------------------
+
+The job of the translation tool chain is to translate RPython_ programs
+into an efficient version of that program for one of various target
+platforms, generally one that is considerably lower-level than Python.
+
+The approach we have taken is to reduce the level of abstraction of the
+source RPython program in several steps, from the high level down to the
+level of the target platform, whatever that may be. Currently we
+support two broad flavours of target platforms: the ones that assume a
+C-like memory model with structures and pointers, and the ones that
+assume an object-oriented model with classes, instances and methods (as,
+for example, the Java and .NET virtual machines do).
+
+The translation tool chain never sees the RPython source code or syntax
+trees, but rather starts with the *code objects* that define the
+behaviour of the function objects one gives it as input. It can be
+considered as "freezing" a pre-imported RPython program into an
+executable form suitable for the target platform.
+
+The steps the translation process can be summarized as follows:
+
+* The code object of each source functions is converted to a `control
+ flow graph` by the `Flow Object Space`_.
+
+* The control flow graphs are processed by the Annotator_, which
+ performs whole-program type inference to annotate each variable of
+ the control flow graph with the types it may take at run-time.
+
+* The information provided by the annotator is used by the RTyper_ to
+ convert the high level operations of the control flow graphs into
+ operations closer to abstraction level of the target platform.
+
+* Optionally, `various transformations`_ can then be applied which, for
+ example, perform optimizations such as inlining or add capabilities
+ such as stackless_-style concurrency.
+
+* Then, the graphs are converted to source code for the target platform
+ and compiled into an executable.
+
+This process is described in much more detail in the `document about
+the translation process`_.
+
+.. _`control flow graph`: translation.html#the-flow-model
+.. _`Flow Object Space`: objspace.html#the-flow-object-space
+.. _Annotator: translation.html#the-annotation-pass
+.. _RTyper: rtyper.html#overview
+.. _`various transformations`: translation.html#the-optional-transformations
+.. _`document about the translation process`: translation.html
+
.. _`standard interpreter`:
.. _`python interpreter`:
@@ -119,33 +176,35 @@
The Python Interpreter
-------------------------------------
-PyPy's *Python Interpreter* implements the Python language
-with the following key components:
+PyPy's *Python Interpreter* is written in RPython and implements the
+full Python language. This interpreter very closely emulates the
+behavior of CPython. It contains the following key components:
- a bytecode compiler responsible for producing Python code objects
+ from the source code of a user application;
- a `bytecode evaluator`_ responsible for interpreting
- Python code objects.
+ Python code objects;
-- a `standard object space`_ responsible for creating, accessing and
- modifying Python application level objects.
+- a `standard object space`_, responsible for creating and manipulating
+ the Python objects seen by the application.
-The *bytecode evaluator* is the part that interprets the compact
-bytecode format produced from user Python sources by a preprocessing
-phase, the *bytecode compiler*. The bytecode compiler itself is
-implemented as a chain of flexible passes (tokenizer, lexer, parser,
-abstract syntax tree builder, bytecode generator). The bytecode
-evaluator does its work by delegating all actual manipulations of
-user objects to the *object space*. The latter can be thought of as the
-library of built-in types. It defines the implementation of the user
-objects, like integers and lists, as well as the operations between
-them, like addition or truth-value-testing.
+The *bytecode compiler* is the preprocessing phase that produces a
+compact bytecode format via a chain of flexible passes (tokenizer,
+lexer, parser, abstract syntax tree builder, bytecode generator). The
+*bytecode evaluator* interprets this bytecode. It does most of its work
+by delegating all actual manipulations of user objects to the *object
+space*. The latter can be thought of as the library of built-in types.
+It defines the implementation of the user objects, like integers and
+lists, as well as the operations between them, like addition or
+truth-value-testing.
This division between bytecode evaluator and object space is very
important, as it gives a lot of flexibility. One can plug in
different `object spaces`_ to get different or enriched behaviours
-of the Python objects. Additionally, a special more abstract object space
-allows to reuse the bytecode evaluator for our translation process.
+of the Python objects. Additionally, a special more abstract object
+space, the `flow object space`_, allows us to reuse the bytecode
+evaluator for our translation framework.
.. _`bytecode evaluator`: interpreter.html
.. _`standard object space`: objspace.html#the-standard-object-space
@@ -154,55 +213,6 @@
.. _`the translation framework`:
-The Translation Process
------------------------
-
-The job of translation tool chain is to translate RPython_ programs into an
-efficient version of that program for one of various target platforms,
-generally one that is considerably lower-level than Python.
-
-.. XXX "vital detail"?
-
-A vital detail of PyPy's approach is that the level of abstraction is
-reduced in several steps from the high level of RPython down to that
-of the target platform, whatever that may be. Currently we support
-two broad flavours of target platforms, one that assumes a C-like
-memory model with structures and pointers and another that assumes an
-object-oriented model with classes, instances and methods.
-
-The translation tool chain never sees Python source code or syntax
-trees, but rather starts with the *code objects* that define the
-behaviour of the function objects one gives it as input.
-
-The steps the translation process can be summarized as follows:
-
- * A code object is converted to a `control flow graph` by the `Flow
- Object Space`_.
-
- * The control flow graphs are processed by the Annotator_, which
- performs whole-program type inference to annotate each variable of
- the control flow graph with the types it may take at run-time.
-
- * The information provided by the annotator is used by the RTyper_ to
- convert the high level operations of the control flow graphs into
- operations closer to abstraction level of the target platform.
-
- * Optionally, `various transformations`_ can then be applied which, for
- example, perform optimizations such as inlining or add capabilities
- such as stackless_-style concurrency.
-
- * Then, the graph is converted to source code for the target platform
- and compiled into an executable.
-
-This process is described in much more detail in the `document about
-the translation process`_.
-
-.. _`control flow graph`: translation.html#the-flow-model
-.. _`Flow Object Space`: objspace.html#the-flow-object-space
-.. _Annotator: translation.html#the-annotation-pass
-.. _RTyper: rtyper.html#overview
-.. _`various transformations`: translation.html#the-optional-transformations
-.. _`document about the translation process`: translation.html
Further reading
===============
@@ -218,14 +228,11 @@
2006.
* `The translation document`_: a detailed description of our
- translation process.
-
- * `Compiling dynamic language implementations`_: a paper describing
- the annotation pass with a greater emphasis on theoretical aspects
- than in the other documentation.
+ translation process. You might also be interested in reading the
+ more theoretically-oriented paper `Compiling dynamic language
+ implementations`_.
- * All our `Technical reports`_. XXX reference specific reports
- and provide a summary here?
+ * All our `Technical reports`_.
.. _`documentation index`: index.html
.. _`getting-started`: getting-started.html
@@ -237,14 +244,14 @@
.. _`getting started`: getting-started.html
.. _`Extreme Programming`: http://www.extremeprogramming.com/
-.. XXX link to this again:
+.. _fast: faq.html#how-fast-is-pypy
.. _`very compliant`: http://www2.openend.se/~pedronis/pypy-c-test/allworkingmodules/summary.html
.. _`RPython`: coding-guide.html#rpython
.. _Python: http://docs.python.org/ref
.. _Psyco: http://psyco.sourceforge.net
-.. _Stackless: http://stackless.com
+.. _stackless: stackless.html
.. include:: _ref.txt
More information about the Pypy-commit
mailing list