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

[davide at codespeak.net]

Author: davide
Date: Fri Dec 19 14:42:49 2008
New Revision: 60591

Modified:
   pypy/extradoc/talk/ecoop2009/clibackend.tex
Log:
changes in reaction of Antonio's comments

Modified: pypy/extradoc/talk/ecoop2009/clibackend.tex
==============================================================================
--- pypy/extradoc/talk/ecoop2009/clibackend.tex	(original)
+++ pypy/extradoc/talk/ecoop2009/clibackend.tex	Fri Dec 19 14:42:49 2008
@@ -65,9 +65,11 @@
 
 \item Each either primary or secondary method implements a certain
   number of blocks, all belonging to the same flow graph. Among these blocks
-  there always exists an initial block whose input variables are
-  parameters of the method; the input variables of all other blocks
-  are local variables of the method. \anto{This is wrong: the signature of the secondary methods is fixed, and input args are passed inside the InputArgs class, not as methodo parameters}
+  there always exists an initial block whose input arguments 
+  might be passed as arguments of the method; however, for
+  implementation  reasons (see the details below) the input variables
+  of all blocks (including the initial one)
+  are implemented as local variables of the method. 
 \end{itemize} 
 
 When  a new case is added to a flexswitch, new blocks are generated
@@ -82,13 +84,12 @@
 by the same method,
  \emph{external} otherwise.
 
-Following an internal link is not difficult in IL bytecode: a jump to
-the corresponding code fragment in the same method is emitted 
-to execute the new block, whereas the appropriate local variables are
-used for passing arguments. \anto{this is wrong for the same reason as above}
-Also following an external link whose target is the initial block of a
-method is not difficult: the corresponding method has to be invoked
-with the appropriate arguments.
+Following an internal link would  not be difficult in IL bytecode: a jump to
+the corresponding code fragment in the same method can be emitted 
+to execute the new block, whereas the appropriate local variables can be
+used for passing arguments. 
+Also following an external link whose target is an initial block could
+be easily implemented, by just invoking the corresponding method.
 
 What cannot be easily implemented in CLI is following an external link
 whose target is not an initial block; consider, for instance, the
@@ -103,8 +104,8 @@
 determine which block has to be executed.
 This is done by passing to the method a 32 bits number, called 
 \emph{block id}, which uniquely identifies the next block of the graph to be executed.
-The high word \anto{a word is 32 bit, block num and method id are 16 bit each} of a block id is the id of the method to which the block
-belongs, whereas the low word is a progressive number univocally identifying
+The high 2 bytes \dacom{word was meant as a fixed-sized group of bits} of a block id constitute the id of the method to which the block
+belongs, whereas the low 2 bytes constitute a progressive number univocally identifying
 each block implemented by the method.
 
 The picture in Figure~\ref{block-id-fig} shows a graph composed of three methods (for
@@ -142,8 +143,7 @@
 \end{small}
 If the next block to be executed is implemented in the same method
 ({\small\lstinline{methodid == MY_METHOD_ID}}), then the appropriate
-jump to the corresponding code is executed, hence internal links
-can be managed efficiently. \anto{wrong: internal links don't go through the dispatcher}
+jump to the corresponding code is executed.
 Otherwise, the \lstinline{jump_to_ext}
 part of the dispatcher has to be executed.
 The code that actually jumps to an external block is contained in