Changes between Version 72 and Version 73 of Orio

Timestamp:

06/14/08 15:02:13 (15 years ago)

Author:

hartono

Comment:

--

Orio

@@ -261 +261 @@
                              preceed the leader annotation 
         ''' 
- 
         self.perf_params = perf_params 
         self.module_body_code = module_body_code 
@@ -280 +279 @@
 Among all the class attributes, three of them are very important in generating optimized code: ''performance parameters'', ''module body code'', and ''annotation body code''. Performance parameters are information essential for performing code optimization and generation, such as unroll factor and tile size. These parameters are stored in a hashtable to facilitate quick accesses to parameter values. The code contained in the module body block normally outlines the applied optimization techniques and, possibly, the high level description of the computation itself. In order to extract this information, new language syntax and a corresponding parser component must be implemented for each transformation module. In addition, the annotation body code, currently expressed in C language, can electively be parsed and given as input to the transformation module. 
 
-In the earlier AXPY-4 case, we can view the annotation body block as redundant, since the module body already contains the same or similar program. The motivation behind requiring Orio users to include the computation itself as part of the annotation is to avoid making use of a full-fledged C compiler infrastructure that potentially will compromise the simplicity, reliability, and portability of Orio. Furthermore, another reason is to allow the computation to be expressed by using domain-specific high-level languages, thus capturing the semantics without imposing tuning constraints resulting from the use of a general-purpose language.
-
-??? simple example of construction of a new module
+In the earlier AXPY-4 case, one could view the module body block as redundant, since the annotation body already contains the same program. The motivation behind requiring Orio users to include the computation itself as part of the annotation is to avoid making use of a full-fledged C compiler infrastructure that potentially will compromise the simplicity, reliability, and portability of Orio. Furthermore, another reason is to allow the computation to be expressed by using domain-specific high-level languages, thus capturing the semantics without imposing tuning constraints resulting from the use of a general-purpose language.
+
+Below, we present a very simple example, which extends Orio with a new module that simply rewrites the annotated code without applying any code transformations at all. The new module has no parser component since there is no necessity to extract information from the annotated code, significantly simplifying the module implementation. First, we need to create a new subdirectory (with a name `simplyrewrite`, for instance) inside `src/module`. And then, we create an ''empty'' special file `__init__.py` inside directory `src/module/simplyrewrite`, so that Python will know that this folder is a package (i.e. a Python module).
+
 
 ''Currently under construction''