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

[pedronis at codespeak.net]

Author: pedronis
Date: Thu Oct  9 03:04:08 2003
New Revision: 1639

Modified:
   pypy/trunk/doc/funding/B1.0_objectives.txt
Log:
first draft of a "Beyond the State of the Art" section.


Modified: pypy/trunk/doc/funding/B1.0_objectives.txt
==============================================================================
--- pypy/trunk/doc/funding/B1.0_objectives.txt	(original)
+++ pypy/trunk/doc/funding/B1.0_objectives.txt	Thu Oct  9 03:04:08 2003
@@ -251,7 +251,64 @@
 Beyond State of The Art
 -----------------------------
 
-empty
+Our architecture is based on Object Spaces, and translation.  The
+interpreter's main dispatch loop handles control flow and supporting
+data structures (frame stack, bytecode objects...); each individual
+operation on objects is dispatched to the object space.
+
+Differently from cited related to work, we don't expect to encode a
+fixed single interpreter in all its details in a subset of our VHLL
+(Python). We plan to exploit the flexibility and abstraction gained by
+the using of the VHLL subset and the indirectness of translation, in
+order to weave aspect such as memory management, object layout etc at
+translation time.
+
+In general we will explore for each feature and extension how to best
+implement it by separating concerns between OO-customized Object
+Spaces, other modules also translated, or the pluggable behavior of
+the translation itself.
+
+Many of these aspects are really cross-cutting concerns in the
+original AOP sense. In general our approach relates to the seminal
+AOP ideas in [kiczales97aspectoriented.pdf], although they have not been
+used on the interpreter for a large practical language. Our subset of
+Python in which to express the core interpreter and Object Spaces is
+the component language in the terminology of the paper, while the
+translator which is also a weaver is expressed in full Python.  For
+describing aspects and at system definition time we will be able to
+use the full dynamism of Python.
+
+For debugging and comprehensibility we expect the core interpreter and
+Object Spaces to be runnable as a normal Python program on a Python
+interpreter.
+
+XXX something about what is innovative in the translator itself?
+XXX currently the "The Translator section"
+
+XXX edit?:
+
+Although Psyco was hand-written, large parts have a one-to-one
+correspondence to whole sections of the C Python interpreter. This is
+uncommon for JITs, but Psyco's good results give ample
+proof-of-concept.  Moreover, this property can be explicitely related
+to the DynamoRIO project cited above, which instrumentates the
+interpreter itself.  Indeed, the one-to-one correspondence between
+parts of C Python and Psyco is as follows: to each expression in C
+Python corresponds a more complex expression in Psyco, which does
+instrumentation and optimisations. The difference with DynamoRIO is
+that the latter analyses the machine code resulting from the
+compilation of the interpreter at run-time. In Psyco, the one-to-one
+correspondance is with the C source instead. It could certainly have
+been done by automated analysis of the C source of C Python, but this
+is difficult and error-prone.
+
+In the PyPy project, on the other hand, the source code of the
+interpreter will be written in Python instead of C. This is much
+easier to analyse safely. Thus, the plan is to raise the level further
+and rely on yet another customisation of the translator, to let it
+emit the complex Psyco-style expressions instead of (or in addition
+to) the normal C expressions that would be the direct translation.
+XXX /edit
 
 :DELETE:BEGIN
 
@@ -564,7 +621,7 @@
 OOPSLA '99, Denver, CO, Nov 2, 1999.
 http://research.sun.com/research/kanban/oopsla-vm-wkshp.pdf
 
-[hlzle91optimizing.pdf] Urs Hlzle, Craig Chambers, and David Ungar,
+[hlzle91optimizing.pdf] Urs Hölzle, Craig Chambers, and David Ungar,
 "Optimizing Dynamically-Typed Object-Oriented Languages with Polymorphic
 Inline Caches", ECOOP'91 Conference Proceedings, Geneva, 1991. Published
 as Springer Verlag Lecture Notes in Computer Science 512, Springer Verlag,
@@ -581,4 +638,9 @@
 [ucpy-reverse-engineering-python.pdf] John Aycock and David Pereira and Georges Jodoin, "UCPy: Reverse-Engineering Python", PyCon DC 2003, 9pp.
 http://pages.cpsc.ucalgary.ca/~aycock/papers/ucpy.pdf
 
+[kiczales97aspectoriented.pdf] Gregor Kiczales and John Lamping and
+    Anurag Menhdhekar and Chris Maeda and Cristina Lopes and Jean-Marc
+    Loingtier and John Irwin, "Aspect-Oriented Programming", ECOOP'97
+http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-ECOOP97/for-web.pdf
+
 :DELETE:END