1. Pypy
  2. Untitled project
  3. extradoc

Commits

Carl Friedrich Bolz  committed 895fed5

add planning for today. move stackless file to paris dir

  • Participants
  • Parent commits b31701a
  • Branches extradoc

Comments (0)

Files changed (3)

File sprintinfo/paris-2005-planning.txt

View file
     ca. 01:00 pm lunch time 
 
 thursday: breakday  (for some of us: eu-consortium meeting) 
+(during the breakday the big room will be needed for the meeting
+from 1pm, so if somebody wants to work in the afternoon, he has to
+go to one of the small rooms)
 
-
-pairing  tuesday
+pairing wednesday
 ======================= 
 
 stackless/cps:   (same group continues, "re-"pairing inside)
     christian, armin 
     Valentino, Amaury 
     Adrien, Anders 
- 
+(see stackless status text soon to be checked in) 
+
 andrew/michael: powerpc-backend   (getting there, continues)
 
 bert, samuele, boris, arre, aurelien: different specialization to more HL-backends
 (defined the "ootypes" model, like the "lltypes" but more OO-ish; will start
  to work on the ootyper, as a branch of the rtyper for now; same group continues
- and may split in two subgroups soon -- backend and ootyper.)
+ and has split in two subgroups soon -- annotator and ootyper.)
 
-llinterpreter:  Carl, Holger
+llinterpreter:  Carl, (Armin later) 
 (starting on the data model of the ll flow graphs, continues)
 
 
-next status meeting: wed 10:30
+next status meeting: fri 10:30
 
 
 later wednesday: 
 discussing compiler & phase 2 work/tasks for the sprint WP09/WP10 
 
+on friday:
+   * short presentation from logilab/dfki about logic programming/AOP
+   * (maybe) presentation about GC work during Summer of Code
+
 peoples present 
 ---------------------
 

File sprintinfo/paris-2005-stackless-discussion.txt

-====================================================
-  Stackless / Continuation discussion group
-====================================================
-
-Bert Freudenberg, Jacob Hall�n, Adrien di Mascio,
-Valentino Volonghi, Christian Tismer
-
-Introduction to current ideas
-------------------------------
-
-We had a small introduction about Stackless Python and
-its implementation. We compared that to PyPy for similarities
-and differences.
-
-The idea is to keep recursion and stack usage as an efficient
-approach using the C compiler and current processor.
-The whole problem of making PyPy stackless is solved by providing
-RPython with a mechanism to unwind and save this stack structure.
-
-An implementation of an example was written by Armin. This
-is thought as a template of how the generated code (c|sh)ould look like.
-
-
-This approach supports
-
-- full continuations, because we can clone the saved block structures
-- restartable exceptions (yet only at the RPython level)
-- pickling program state
-- unlimited recursion
-- context switching
-- garbage collection with explicit knowledge of all roots
-
-
-General impressions
---------------------
-
-The proposed stackless extension of the existing framework
-might be easier to implement than a new approach using
-continuation passing style. But we might want to try
-examples for both and compare performance.
-
-Needed independently of the backend:
-being able to capture variables of a block.
-This could work on the annotated flowgraph, but probably makes
-more sense after all the backend optimizations. It is still
-the same for all backends.
-
-Needed action:
-Find the set of necessary structures to describe the status of all blocks.
-Generate types for all the variants of blocks. The concrete implementation
-may vary. The current simple approach is a block number that encodes
-function, arity, return type of the function and relative block
-number. Different encodings are possible and may vary per backend.
-(In assembly, one would probably add descriptor info right before
-the function entrypoint...)
-
-Aliveness considerations, partially related to the backend:
-The state blocks take over the role of the stack. The stack may
-instead be considered as a cache for the state blocks. State
-blocks are actually a synonym for continuations.
-
-
-Backend:
-
-Tasks for implementation:
-
-- generating the structures for saving the blocks
-- generate extra code for function re-entry
-- write extra support for detecting stack overflows.
-
-  + have extra info about the stack size of every function.
-
-Thinking about re-use of the existing exception handling code,
-which is there for every function call. Adding yet another case
-might be cheap. See if this is simpler or more complex
-than using extra variables.
-
-Observations:
--------------
-
-We can use this mechanism to produce restartable exceptions. But this
-is not about Python-level exceptions without further support.
-
-This approach appears to give us full continuations for free.
-

File sprintinfo/paris/paris-2005-stackless-discussion.txt

View file
+====================================================
+  Stackless / Continuation discussion group
+====================================================
+
+Bert Freudenberg, Jacob Hall�n, Adrien di Mascio,
+Valentino Volonghi, Christian Tismer
+
+Introduction to current ideas
+------------------------------
+
+We had a small introduction about Stackless Python and
+its implementation. We compared that to PyPy for similarities
+and differences.
+
+The idea is to keep recursion and stack usage as an efficient
+approach using the C compiler and current processor.
+The whole problem of making PyPy stackless is solved by providing
+RPython with a mechanism to unwind and save this stack structure.
+
+An implementation of an example was written by Armin. This
+is thought as a template of how the generated code (c|sh)ould look like.
+
+
+This approach supports
+
+- full continuations, because we can clone the saved block structures
+- restartable exceptions (yet only at the RPython level)
+- pickling program state
+- unlimited recursion
+- context switching
+- garbage collection with explicit knowledge of all roots
+
+
+General impressions
+--------------------
+
+The proposed stackless extension of the existing framework
+might be easier to implement than a new approach using
+continuation passing style. But we might want to try
+examples for both and compare performance.
+
+Needed independently of the backend:
+being able to capture variables of a block.
+This could work on the annotated flowgraph, but probably makes
+more sense after all the backend optimizations. It is still
+the same for all backends.
+
+Needed action:
+Find the set of necessary structures to describe the status of all blocks.
+Generate types for all the variants of blocks. The concrete implementation
+may vary. The current simple approach is a block number that encodes
+function, arity, return type of the function and relative block
+number. Different encodings are possible and may vary per backend.
+(In assembly, one would probably add descriptor info right before
+the function entrypoint...)
+
+Aliveness considerations, partially related to the backend:
+The state blocks take over the role of the stack. The stack may
+instead be considered as a cache for the state blocks. State
+blocks are actually a synonym for continuations.
+
+
+Backend:
+
+Tasks for implementation:
+
+- generating the structures for saving the blocks
+- generate extra code for function re-entry
+- write extra support for detecting stack overflows.
+
+  + have extra info about the stack size of every function.
+
+Thinking about re-use of the existing exception handling code,
+which is there for every function call. Adding yet another case
+might be cheap. See if this is simpler or more complex
+than using extra variables.
+
+Observations:
+-------------
+
+We can use this mechanism to produce restartable exceptions. But this
+is not about Python-level exceptions without further support.
+
+This approach appears to give us full continuations for free.
+