[pypy-svn] r63752 - pypy/extradoc/talk/icooolps2009-dotnet

[davide at codespeak.net]

Author: davide
Date: Mon Apr  6 23:36:27 2009
New Revision: 63752

Modified:
   pypy/extradoc/talk/icooolps2009-dotnet/intro.tex
Log:
small corrections, a comment added

Modified: pypy/extradoc/talk/icooolps2009-dotnet/intro.tex
==============================================================================
--- pypy/extradoc/talk/icooolps2009-dotnet/intro.tex	(original)
+++ pypy/extradoc/talk/icooolps2009-dotnet/intro.tex	Mon Apr  6 23:36:27 2009
@@ -76,8 +76,8 @@
 
 The main difference between the JIT compilers generated by PyPy and the
 ones found in other projects like IronPython is that the latter compile
-code at the method granularity -- if on the one hand they can exploit
-some of the knowledge gathered at runtime (e.g.\ the types of method
+code at the method granularity: if on the one hand they can exploit
+some of the knowledge gathered at runtime \davide{this contradicts what is stated in the intro} (e.g.\ the types of method
 parameters), on the other hand they can do little to optimize most of
 the operations inside, because few assumptions can be made about the
 global state of the program.  The PyPy JITs, on the other hand, work at
@@ -86,7 +86,7 @@
 When using PyPy, the first step is to write an interpreter for the chosen language.  Since it
 must be fed to the translation toolchain, the interpreter has to be written in
 RPython.  Then, to guide the process, we need to add few manual
-annotations to the interpreter, in order to teach the JIT generator which
+annotations (called hints) to the interpreter, in order to teach the JIT generator which
 information is important to know at compile-time.  
 From these annotations, PyPy will statically generate an interpreter and a JIT
 compiler in a single executable (here a .NET executable).
@@ -110,11 +110,11 @@
 Potentially, the JIT compiler generates new code for each different run-time
 value seen in variables it is interested in.
 This implies that the generated code needs to contain some sort of updatable
-switch, or \emph{flexswitch}, which can pick the right code path based on the
+switch, called \emph{flexswitch}, which can pick the right code path based on the
 run-time value.  Typically, the value we switch on is the runtime dynamic type
 of a value, so that the JIT compiler has all information needed to produce
 very good code for that specific case.
 
 Modifying the old code to link to the newly generated one is very challenging on
 .NET, as the framework does not offer any primitive to do this.  Section
-\ref{sec:clibackend} explains how it is possible to simulate this behaviour.
+\ref{sec:clibackend} explains how it is possible to obtain this behaviour.