[pypy-svn] r45312 - pypy/extradoc/talk/dyla2007

cfbolz at codespeak.net cfbolz at codespeak.net
Wed Jul 25 00:37:22 CEST 2007


Author: cfbolz
Date: Wed Jul 25 00:37:20 2007
New Revision: 45312

Modified:
   pypy/extradoc/talk/dyla2007/talk.tex
Log:
somewhat uninspired pypy section


Modified: pypy/extradoc/talk/dyla2007/talk.tex
==============================================================================
--- pypy/extradoc/talk/dyla2007/talk.tex	(original)
+++ pypy/extradoc/talk/dyla2007/talk.tex	Wed Jul 25 00:37:20 2007
@@ -274,20 +274,114 @@
 \end{frame}
 
 \begin{frame}
-  \frametitle{}
+  \frametitle{PyPy's Approach to VM Construction}
   \begin{itemize}
   \item
+    Goal: achieve flexibility, simplicity and performance all at one
+  \item
+    Approach: auto-generate VMs from high-level descriptions of the language
+  \item
+    ... using meta-programming techniques and aspects (in the original sense)
+  \item
+    high-level description of the language done by writing an interpreter in
+    RPython
   \end{itemize}
   \pause
   \begin{block}{
-    Python Case}
+    What is RPython}
     \begin{itemize}
     \item
+      RPython is a subset of Python
+    \item
+      subset chosen in such a way that type-inference can be performed
+    \item
+      still a high-level language (unlike SLang or Prescheme)
     \end{itemize}
   \end{block}
 \end{frame}
 
+\begin{frame}
+  \frametitle{Auto-generating VMs}
+  \begin{itemize}
+  \item
+    interpreters written in RPython can be translated to various targets:
+    C/Posix, CLR, JVM
+  \item
+    VMs generated by a flexible translation toolchain (really a compiler)
+  \end{itemize}
+  \begin{block}{
+    Translation Aspects}
+    \begin{itemize}
+    \item
+      the translation toolchain weaves in various aspect into the generated VM
+    \item
+      examples: GC strategy, threading model
+    \item
+      early design decisions not necessary
+    \item
+      non-trivial translation aspect: auto-generating a dynamic compiler from
+      the interpreter % XXX maybe we really want to write more about this
+    \end{itemize}
+  \end{block}
+\end{frame}
 
+\begin{frame}
+  \frametitle{Good Points of the Approach}
+  \begin{itemize}
+  \item
+    dynamic languages can implemented in a high level language
+  \item
+    doing this separates high-level from low-level concerns
+  \item
+    generating various VMs from a single source interpreter, which is easy to
+    write
+  \item
+    lots of flexibility at all levels:
+    \begin{itemize}
+    \item
+      when writing the interpreter
+    \item
+      also possible to adapt the translation toolchain if necessary
+    \item
+      this allows breaking of abstraction barriers, when necessary (e.g. tagged
+      integers)
+    \end{itemize}
+  \end{itemize}
+\end{frame}
+
+\begin{frame}
+  \frametitle{Open Issues / Drawbacks / Further Work}
+  \begin{itemize}
+  \item
+    writing the translation toolchain in the first place takes lots of effort
+    (but it can be reused)
+  \item
+    writing a good GC is still necessary. but: can we maybe reuse existing good
+    GCs (e.g. from the Jikes RVM)?
+  \item
+    many abstraction layers
+  \item
+    dynamic compiler generation seems to work, but needs to be improved
+  \end{itemize}
+\end{frame}
+
+\begin{frame}
+  \frametitle{Conclusion / Meta-Points}
+  \begin{itemize}
+  \item
+    high-level languages are suitable to implement dynamic languages
+  \item
+    doing so has many benefits
+  \item
+    VM's shouldn't be written by hand
+  \item
+    PyPy's concrete approach is not so important
+  \item
+    diversity is good
+  \item
+    let's write more meta-programming tool-chains!
+  \end{itemize}
+\end{frame}
 
 \begin{frame}
   \frametitle{}



More information about the Pypy-commit mailing list