Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
research:dsal:rg [2008/12/29 18:46] – created jfabryresearch:dsal:rg [2009/01/08 20:05] (current) – jfabry
Line 1: Line 1:
 +===== RG =====
 +(Internal classification: historical)
 +
 +Reference paper: **"Aspect-Oriented Programming"** Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, John Irwin, In //ECOOP'97 -- Object-Oriented Programming//, Springer LNCS Volume 1241, P220 -- 242 , 1997. 
 +
 +There is a Xerox PARC techreport ((**RG: A Case-Study for Aspect-Oriented Programming** Anurag Mendhekar, Gregor Kiczales, John Lamping, Xerox PARC technical Report SPL97-009, 1997)) but this however does not give any more detailed information.
 +
 +From Lopes' history paper ((**Aspect-Oriented Programming: An Historical Perspective (What's in a Name?)** Christina Videira Lopes [[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.58.7760]])):
 +> Although the optimization of memory usage has never, since then, been analyzed as an aspect, the RG example was actually very interesting, and it was chosen as the leading example in the first AOP paper (Kiczales et al. ECOOP 1997).
 +
 +===== Domain of the language =====
 +
 +An image processing system in which model is one of images passing through a series of filters, implemented as procedures. (RG stands for Reverse Graphics)
 +
 +===== Intent of the language =====
 +
 +Optimization of memory usage when composing filters by performing loop fusion. When each filter procedure is called, it loops over a number of input images and produces a new output image. Output images only exist briefly before being consumed by another loop. Results are "excessively frequent memory references and storage allocation, which in turn leads to cache misses, page faults and terrible performance". 
 +
 +(In the original techreport referenced in the paper computation and cache use optimisation is also mentioned.) 
 +
 +===== Join Point Model and Advice Model =====
 +
 +  * JPM: Domain-Specific: All message sends to filter procedures. Join Points are data flow graphs of all message sends to filters. Nodes represent filters, edges represent an image flowing from filter to filter.
 +  * AM: Domain-Specific: "A simple procedural language that provides simple operations in the dataflow graph."
 +
 +
 +===== Anatomy of the language =====
 +
 +The grammar of the language is not explicitly described, a Common Lisp syntax is used in the examples.
 +
 +===== Typical Example =====
 +
 +The example from the paper we reference (which is the same as in the techreport): 
 +
 +  (cond ((and (eq (loop-shape node) 'pointwise)
 +              (eq (loop-shape input) 'pointwise))
 +         (fuse loop input 'pointwise
 +                 :inputs (splice ...)
 +                 :loop-vars  (splice ...)
 +                 :body  (subst ...))))
 +
 +The example "checks whether two nodes connected by a data flow edge both have a pixelwise loop structure, and if so it fuses them into a single loop that also has a pixelwise structure and that has the appropriate merging of the inputs, loop variables and body".
 +
 +===== Enforced Restrictions =====
 +
 +No explicit mention is made of restrictions in the advice language.
 +
 +===== Implementation description =====
 +
 +Weaving is done through source code transformation: from the lisp-like base language and the aspect languages to C code. The weaver "uses unfolding as a technique for generating a data flow graph from the component program". The aspect programs manipulate this graph directly. The resulting graph is passed to a C code generator.
 +
 +