[pypy-svn] r27641 - pypy/extradoc/talk/dls2006

[arigo at codespeak.net]

Author: arigo
Date: Wed May 24 13:16:13 2006
New Revision: 27641

Added:
   pypy/extradoc/talk/dls2006/draft.txt   (contents, props changed)
Modified:
   pypy/extradoc/talk/dls2006/   (props changed)
   pypy/extradoc/talk/dls2006/outline.txt
Log:
Started working on a draft.


Added: pypy/extradoc/talk/dls2006/draft.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/talk/dls2006/draft.txt	Wed May 24 13:16:13 2006
@@ -0,0 +1,158 @@
+************************************************************
+                  Still Missing a Cool Title
+************************************************************
+
+:Abstract:
+
+    The PyPy project seeks to prove both on a research and on a
+    practical level the feasability of writing a virtual machine (VM)
+    for a dynamic language in a dynamic language - in this case, Python.
+    The aim is to translate (i.e. compile) the VM to arbitrary target
+    environments, ranging in level from C/Posix to Smalltalk/Squeak via
+    Java and CLI/.NET, while still being of reasonable efficiency within
+    that environment.
+
+    A key tool to achieve this goal is the systematic reuse of the
+    (unmodified, dynamically typed) Python language as a system
+    programming language at various levels of our architecture and
+    translation process.  For each level, we design a corresponding type
+    system and apply a generic type inference engine - for example, the
+    garbage collector (GC) is written in a style that manipulates
+    simulated pointer and address objects, and when translated to C
+    these operations become C-level pointer and address instructions.
+
+.. sectnum::
+
+
+.. _`section 1`:
+
+============================================================
+                         Introduction
+============================================================
+
+
+Despite the constant trend in the programming world towards portability
+and reusability, there are some areas in which it is still notoriously
+difficult to write flexible, portable, and reasonably efficient
+programs.  Virtual machines (VM) is one such area.  Building
+implementations of general programming languages, in particular highly
+dynamic ones, is typically a long-winded effort and produces a result
+that is quite tailored to a specific platform.  For this and other
+reasons, standard platforms emerge; nowadays, a language implementor
+could cover most general platforms in use by writing three versions of
+his VM: for C/Posix, for Java, and for CLI/.NET.  This is, at least, the
+current situation of the Python programming language, where independent
+volunteers developped and are now maintaining Java and .NET versions of
+Python, which follow the evolution of the "official" C version
+(CPython).
+
+However, we believe that platform standardization does not have to be a
+necessary component of this equation.  We are basically using the
+standard "metaprogramming" argument: if one could write the VM in a
+very-high-level language, then the VM itself could be automatically
+*translated* to any lower-level platform.  Moreover by writing the VM in
+such a language we would gain in flexibility and expressivity.
+
+PyPy achieves this goal without giving up on the efficiency of the
+compiled VMs.  The key factors enabling this result are not to be found
+in recent advances in any particular research area - we are not using
+any sophisticated GC, any constraint-based type inference, any advanced
+mega-programming concepts.  Instead, we are following a novel overall
+architecture: it is split in many levels of stepwise translation from
+the high-level source of the VM to the final target platform.  Similar
+platforms can reuse many of these steps, while for very different
+platforms we have the option to perform very different translation
+steps.  Each step reuses a common type inference component, but with a
+different type system.
+
+Experiments also suggest a more mundane reason why such an approach is
+only practical today: a typical translation takes about an hour on a
+modern PC and consumes close to 1GB of RAM.
+
+We shortly describe the architecture of PyPy in `section 2`_.  In
+`section 3`_ we describe our approach of varying the type systems at
+various levels of the translation.  `Section 4`_ gives an overview of
+the type inferencer we developped.  We present experimental results in
+`section 5`_ and future work directions in `section 6`_.  In `section 7`_
+we compare with related work, and finally we conclude in `section 8`_.
+
+
+.. _`section 2`:
+
+============================================================
+                        Architecture
+============================================================
+
+
+XXX it contains on
+the one hand an implementation of the Python programming language,
+mostly complete and compliant with the current version of the language,
+Python 2.4.  Our current efforts are focused on the second part, which
+is a translation toolsuite whose goal is, roughly speaking, to compile
+various subsets of Python to various environment.
+
+
+
+.. _`section 3`:
+
+============================================================
+                 System programming with Python
+============================================================
+
+
+XXX
+
+
+
+.. _`section 4`:
+
+============================================================
+                        Type inference
+============================================================
+
+
+XXX
+
+
+
+.. _`section 5`:
+
+============================================================
+                     Experimental results
+============================================================
+
+
+XXX
+
+
+
+.. _`section 6`:
+
+============================================================
+                        Future work
+============================================================
+
+
+XXX
+
+
+
+.. _`section 7`:
+
+============================================================
+                        Related work
+============================================================
+
+
+XXX
+
+
+
+.. _`section 8`:
+
+============================================================
+                        Conclusion
+============================================================
+
+
+XXX

Modified: pypy/extradoc/talk/dls2006/outline.txt
==============================================================================
--- pypy/extradoc/talk/dls2006/outline.txt	(original)
+++ pypy/extradoc/talk/dls2006/outline.txt	Wed May 24 13:16:13 2006
@@ -6,9 +6,14 @@
 Introduction
 ============
 
-High-level architecture, VM portability+flexibility goals with comparisons
+VM portability+flexibility goals with comparisons
 (rigidity, less expressiveness of implementation languages)
 
+Architecture
+============
+
+High-level architecture, shortly
+
 System programming with Python
 ==============================
 
@@ -27,6 +32,11 @@
 and to reuse with different type systems: RPython, ll, oo, rctypes,
 BTA (binding-time analysis for the JIT)...  easy custom specializations
 
+Experimental results
+====================
+
+a few numbers
+
 Future work
 ===========