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

[cfbolz at codespeak.net]

Author: cfbolz
Date: Thu Dec 18 15:19:42 2008
New Revision: 60573

Modified:
   pypy/extradoc/talk/ecoop2009/tlc.tex
Log:
fix some things in the tlc section


Modified: pypy/extradoc/talk/ecoop2009/tlc.tex
==============================================================================
--- pypy/extradoc/talk/ecoop2009/tlc.tex	(original)
+++ pypy/extradoc/talk/ecoop2009/tlc.tex	Thu Dec 18 15:19:42 2008
@@ -1,11 +1,14 @@
 \section{The TLC language}
 
 In this section, we will briefly describe \emph{TLC}, a simple dynamic
-language that we developed to exercise our JIT compiler generator.  As most of
-dynamic languages around, \emph{TLC} is implemented through a virtual machine
-that interprets a custom bytecode. Since our main interest is in the runtime
-performance of the VM, we did not implement the parser nor the bytecode
-compiler, but only the VM itself.
+language that we developed to exercise our JIT compiler generator and that will
+be used as a running example in this paper. The design goal of the language is
+to be very simple (the interpreter of the full language consists of about 600
+lines of RPython code) but to still have the typical properties of dynamic
+languages that make them hard to compile. \emph{TLC} is implemented with a small
+interpreter that interprets a custom bytecode instruction set. Since our main
+interest is in the runtime performance of the interpreter, we did not implement
+the parser nor the bytecode compiler, but only the interpreter itself.
 
 TLC provides four different types:
 \begin{enumerate}
@@ -20,12 +23,14 @@
 of attributes of the object, as well as its methods.  Once the object has been
 created, it is not possible to add/remove attributes and methods.
 
-The virtual machine is stack-based, and provides several operations:
+The interpreter for the language is stack-based and uses bytecode to represent
+the program. It provides the following bytecode instructions:
 
 \begin{itemize}
 \item \textbf{Stack manipulation}: standard operations to manipulate the
-  stack, such as \lstinline{PUSH}, \lstinline{POP}, \lstinline{SWAP}, etc.
+  stack, such as \lstinline{POP}, \lstinline{PUSHARG}, \lstinline{SWAP}, etc.
 \item \textbf{Flow control} to do conditional and unconditional jumps.
+\cfbolz{what is the bytecode for conditional jumps?}
 \item \textbf{Arithmetic}: numerical operations on integers, like
   \lstinline{ADD}, \lstinline{SUB}, etc.
 \item \textbf{Comparisons} like \lstinline{EQ}, \lstinline{LT},
@@ -44,18 +49,20 @@
 
 \subsection{TLC features}
 \label{sec:tlc-features}
+\cfbolz{calling this sections "features" is a bit obscure, since it is more
+properties of the implementation}
 
 Despite being very simple and minimalistic, \lstinline{TLC} is a good
 candidate as a language to test our JIT generator, as it has some of the
-features that makes most of current dynamic languages so slow:
+properties that makes most of current dynamic languages so slow:
 
 \begin{itemize}
 
-\item \textbf{Stack based VM}: this kind of VM requires all the operands to be
+\item \textbf{Stack based interpreter}: this kind of interpreter requires all the operands to be
   on top of the evaluation stack.  As a consequence programs spend a lot of
   time pushing and popping values to/from the stack, or doing other stack
   related operations.  However, thanks to its simplicity this is still the
-  most common and preferred way to implement VMs.
+  most common and preferred way to implement interpreters.
 
 \item \textbf{Boxed integers}: integer objects are internally represented as
   an instance of the \lstinline{IntObj} class, whose field \lstinline{value}
@@ -82,7 +89,7 @@
 main:             # stack: []
     PUSHARG       #        [n]
     PUSH 0        #        [n, 0]
-    LT            #        [n<0]
+    LT            #        [0 or 1]
     BR_COND neg
 
 pos:              #        []