[pypy-svn] rev 1913 - pypy/trunk/doc/funding

[arigo at codespeak.net]

Author: arigo
Date: Tue Oct 14 18:11:22 2003
New Revision: 1913

Modified:
   pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
Log:
More careful usage of the words "translation" and "translator".


Modified: pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
==============================================================================
--- pypy/trunk/doc/funding/B6.0_detailed_implementation.txt	(original)
+++ pypy/trunk/doc/funding/B6.0_detailed_implementation.txt	Tue Oct 14 18:11:22 2003
@@ -53,7 +53,7 @@
 in Python. It must be entierely compatible with the language specification. It
 consists of the following major parts:
 
-- A *bytecode compiler,* which translates Python source code into an internal
+- A *bytecode compiler,* which inputs Python source code and outputs an internal
   intermediate representation, the *bytecode.*
 
 - A *bytecode interpreter,* which interprets bytecodes and manages the
@@ -77,7 +77,7 @@
 C that are either standard or widely-used in CPython. (The Python Standard
 Library is already mostly written in Python, so that the problem only concerns
 C-coded extension modules.) For each extension module, two strategies can be
-followed: either the module is translated into a (regular) Python module, or
+followed: either the module is rewritten as a (regular) Python module, or
 it is written as an extension module of the PyPy interpreter (i.e. in Python
 too, but at the level of the interpreter.)
 
@@ -102,8 +102,9 @@
 of a compilation process.
 
 We are giving translation an innovative emphasis (and thus a whole
-workpackage, WP05_) in the project. It is not merely an RPython-to-C
-translator; it is an essential part of our flexibility goals. Numerous aspects
+workpackage, WP05_) in the project. It is not only an RPython-to-C
+translator; it is a source-to-source transformer, and as such an
+essential part of our flexibility goals. Numerous aspects
 that used to be design decisions influencing the whole source code of the
 current CPython have by now become merely customizable behaviour of the
 translator.  Indeed, instead of hard-coding such design decisions, we will
@@ -205,12 +206,12 @@
   this idea, which has been first tried for Python in the Stackless project.
 
 - Generating a JIT compiler. Existing work in the Psyco project has shown that
-  it would actually be possible to mostly generate a JIT compiler instead of
+  it would actually be possible to generate the most part of a JIT compiler instead of
   having to write it from scratch. The basic idea is again abstract
   interpretation: instead of actually performing any operation between two
   objects, we *generate* machine code that can perform the required operation.
   Again, no change to the bytecode interpreter is needed; all we need is to
-  translate individual operations to processor instructions, together with a
+  turn individual operation orders into processor instructions, together with a
   supporting runtime systems. This is defined by WP08_.
 
 In dynamic languges, the truth behind JIT compiling is a bit more involved
@@ -224,10 +225,13 @@
 the RPython source (i.e. the bytecode interpreter and the standard Object
 Space). We plan to write the dynamic part of the JIT as a plug-in to the
 translator: instead of generating C code that is the direct translation of
-PyPy, we will generate C code that itself generates machine code. This extra
-indirection has large benefits: the operations the JIT need to be taught about
-are only the ones allowed in RPython. The resulting piece of C code will thus
-be the JIT-enabled version of PyPy.
+PyPy, we will generate C code (with the translator) that itself generates
+machine code (by directly emitting it as bytes into memory). This extra
+indirection has large benefits: the operations the JIT need to be manually taught
+about for the generation of machine code are only the ones allowed in RPython.
+In other words, we only need to design a JIT supporting the low-level operations
+of RPython; still, the translated piece of C code that we obtain is a JIT-enabled
+version of PyPy that supports the whole of the Python language.
 
 
 Other research aspects