[pypy-svn] rev 2694 - pypy/trunk/doc

[hpk at codespeak.net]

Author: hpk
Date: Sun Dec 28 19:05:36 2003
New Revision: 2694

Modified:
   pypy/trunk/doc/architecture.txt
Log:
Wrote a higher level instruction to our architecture. 



Modified: pypy/trunk/doc/architecture.txt
==============================================================================
--- pypy/trunk/doc/architecture.txt	(original)
+++ pypy/trunk/doc/architecture.txt	Sun Dec 28 19:05:36 2003
@@ -1,16 +1,52 @@
-Overview on PyPy's current architecture  (Dec. 2003)
-====================================================
+Overview on PyPy's current architecture (Dec. 2003)
+===================================================
+
+
+Introduction and higher level picture
+-------------------------------------
 
 The various parts of PyPy have always been under more or less heavy
 refactoring during our five one-week sprints in 2003.  However, the
-basic architecture remains rather simple and unchanged: a plain
-*interpreter* reads and dispatches *bytecodes*, shuffling objects around
-on the stack and between namespaces of which it knows almost nothing.
-For any operation on an object, the interpreter delegates to a so-called
-"Object Space", which performs creation, modification, access, and
-destruction of objects.  Such objects are often refered to as
-*application-level objects*, because they are the objects you naturally
-work with from a python program. 
+higher level architecture remains rather simple and unchanged.  There
+are two independent basic subsystems:
+
+- the *standard interpreter* which implements the Python language 
+  and is composed out of two components:
+
+  - the *plain interpreter* which is responsible for interpreting 
+    code objects and implementing bytecodes,
+
+  - the *standard object space* which implements creation, access and
+    modification of application level objects,
+
+  Note that the *standard interpreter* can run fine on top of CPython 
+  (the C Implementation of Python led by Guido van Rossum) but of course
+  the double-interpretation penalty lets us interpret python programs
+  rather slowly. 
+
+- the *translation process* which aims at producing a different (low-level)
+  representation of our standard interpreter.  The *translation process* 
+  is done in three steps: 
+
+  - producing a *flow graph* representation of the standard interpreter. 
+    A combination of a *plain interpreter* and a *flow object space*
+    performs "abstract interpretation" to record the flow of objects
+    and execution throughout a python program into such a *flow graph*. 
+
+  - the *annotator* which performs type inference on the flow graph 
+
+  - the *translator* which translates the (annotated) flow graph into
+    another language, currently Pyrex/C and LISP.  
+
+Please note that we are using the term *interpreter* most often in
+reference to the *plain interpreter* which just knows enough to read,
+dispatch and implement *bytecodes* thus shuffling objects around on the
+stack and between namespaces.  The (plain) interpreter is completly
+ignorant of how to access, modify or construct objects and their
+structure and thus delegates such operations to a so called "Object Space". 
+
+XXX mention Parser and compiler (we have one available since the Berlin
+sprint but it is not integrated)
 
 The Interpreter
 ===============