[pypy-svn] r60572 - pypy/extradoc/talk/ecoop2009

[cfbolz at codespeak.net]

Author: cfbolz
Date: Thu Dec 18 15:18:00 2008
New Revision: 60572

Modified:
   pypy/extradoc/talk/ecoop2009/intro.tex
Log:
some notes about what the high-level overview should contain


Modified: pypy/extradoc/talk/ecoop2009/intro.tex
==============================================================================
--- pypy/extradoc/talk/ecoop2009/intro.tex	(original)
+++ pypy/extradoc/talk/ecoop2009/intro.tex	Thu Dec 18 15:18:00 2008
@@ -15,15 +15,20 @@
 runtime; this approach seems to work, but writing it manually requires an
 enormous effort.
 
-\cfbolz{we should cite the dyla paper somewhere here}
+\cfbolz{we should cite the dyla paper somewhere here. also, we generally need
+more references}
 
-PyPy's idea is to automatize the generation of JIT compilers in order
+PyPy's approach is to automatize the generation of JIT compilers in order
 to reduce to a minimum the effort required to get a fast implementation of a
 dynamic language; all you have to do is to write a high level specification of
 the language (by writing an interpreter), and putting it through PyPy's
 translation toolchain. The automatic generation of JIT compilers is done with
 the help of partial evaluation techniques.
 
+The contributions of this paper are \emph{promotion}, a generalization of
+polymorphic inline caches that make partial evaluation practical for dynamic
+languages and trying out the idea of JIT-layering XXX.
+
 \subsection{PyPy and RPython}
 
 \anto{as Armin points out, the two CLI backends can be easily confused; what
@@ -38,7 +43,7 @@
 \end{center}
 \end{figure}
 
-The \emph{PyPy} project\footnote{\texttt{http://codespeak.net/pypy/dist/pypy/doc/home.html}}
+The \emph{PyPy} project\footnote{\texttt{http://codespeak.net/pypy/}}
 \cite{RigoPedroni06} was initially conceived to develop an implementation of Python which
 could be easily portable and extensible without renouncing efficiency.
 To achieve these aims, the PyPy implementation is based on a highly
@@ -77,9 +82,26 @@
 This section will give a high-level overview of how the JIT-generation process
 works. More details will be given in subsequent sections.
 
+- write an interpreter
+- add some hints to the interpreter
+
+translation time:
+- start the translation process, flow graphs
+- run a binding-time analysis using the hints, to figure out ...
+- turn the flow graphs into rainbow bytecode
+- turn the flow graphs of the rainbow interpreter and the original flow graphs
+into .NET code
+
+runtime:
+when the interpreter is started and a function should be interpreted:
+ - the generated JIT starts compiling the function 
+ - it produces .NET bytecode until it does not have enough information to
+ continue. then it stops the compilation and puts a callback into the compiler
+ into the generated bytecode.
+ - at this point the .NET bytecode that is produced so far is executed.
+ - when the callback into the compiler is hit, execution stops and compilation
+ starts again
+ - afterwards execution continues after the callback (running the code that was
+ newly produced)
 
-Another interesting feature of PyPy
-is that just-in-time compilers can be semi-automatically generated from the
-interpreter source.
 
-XXX list contributions clearly