JP2003233499A - Method for aspect oriented programming with multiple semantic levels - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method for aspect oriented programming with multiple semantic levels. <P>SOLUTION: Some aspects need access to more information than information available at a basic level in conjunction with program data for one or a plurality of objects. An aspect of aspect oriented systems, a method and an environment checks results of calculation at one stage. The aspect only affects the following calculation stage, as a consequence, no circulation exists. The aspect, furthermore, implements local or global analysis at each stage and can propagate non-local information. A method for aspect oriented programming can eliminate or decrease a 'macro' style programming, therefore, the programming becomes easy by manipulating results of the several calculation stages without manipulating code blocks. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION The present invention relates to methods and systems for aspect-oriented programming using a general purpose semantic invariant construct language.

[0002]

BACKGROUND OF THE INVENTION Currently, the main concept in constructing complex software systems is the object-oriented programming paradigm. The idea behind object-oriented programming is to subdivide the software system into smaller modular units such as classes, objects, methods (or functions). At compile time, each modular unit used in object-oriented programming has a separate code
Approximately corresponds to a block. Since these blocks of code execute regardless of the structure of other blocks, unnecessary redundant operations often occur. Therefore, if the methods can "talk" to each other, the overall speed of the software system can be increased. Some large time-dependent software systems can benefit greatly from methods "talking" to each other.

In aspect-oriented programming, programmers, like object-oriented programming,
Abstraction and decomposition can be used to break a large problem into smaller manageable sub-parts. However, the problem is subdivided according to aspect-based decomposition rather than function-based decomposition. Aspects facilitate "conversation" between methods. Furthermore, the aspects “talk” to each other
Or it can be traversed, resulting in a traversable executable program.

[0004]

[Patent Document 1] US Pat. No. 5,882,593

[0005]

According to various existing general-purpose aspect-oriented programming techniques, it is possible to intercept and arbitrate the operations of a basic program. However, these techniques are limited in that they are limited by the same limited view of program data currently available at the base level of objects or methods. Some aspects require access to more information about the program data of one or more objects than is available at the base level.

In the context of the example aspect-oriented programming presented above, there are obvious difficulties in implementing conventional aspect-oriented programming techniques in many desirable implementations, due to the circular nature of the purpose of the aspect and its requirements. It is clear that there is. That is, a particular aspect needs access to the calculations to obtain the data that the aspect requires. However, the aspect itself affects the calculation. In other words, the aspect needs to look at something by an object or module to perform its operation, which will be determined, at least in part, by what the aspect will do to it later.

[0007]

An "aspect" is a unique code set in an aspect-oriented program, just as an object is a unique code set in an object-oriented program. In various exemplary embodiments of systems, methods, and aspect-oriented programming language environments according to this invention, an aspect examines the results of a computation in one step. This aspect only affects the subsequent calculation stages, so there is no cycle.

According to one aspect of the invention, a method for simplifying a programming element compilable into instructions for operating a data processing device, the programming element having at least one part, said method comprising: Determining the process of simplifying the programming elements until at least one part of them all reaches the first stage to produce the current stage simplified programming elements and at least one propagator for the current stage simplified programming elements Where the propagator is described in the programming element, and using at least one propagator determined, associating at least one projection with the current simplified programming element, and Computerized programming elements and functions Based at least in part on the projection to simplify the current stage simplified programming element until all of at least one part of it reaches the next stage to produce the next stage simplified programming element. Including.

[0009]

DETAILED DESCRIPTION OF THE INVENTION FIG. 1 illustrates an exemplary embodiment of a conventional aspect-oriented programming environment 100.
In particular, FIG. 1 shows how a programming element is converted into an executable software module using a conventional aspect-oriented programming language. Figure 1
As shown in FIG. 1, one or more high level computer programming elements 120 are provided to the aspect oriented weaver 110. Aspect-oriented weaver 110 within aspect-oriented programming environment 100 compiles each high-level computer program element 120 into one or more executable modules. Aspect-oriented weaver 110
Can be either static or dynamic. The automatic aspect-oriented weaver 110 implements a static weaving process. The static weaving process inserts aspect-specific statements at join points in high-level programming elements 120, such as class source code, to allow such high-level programming elements 12 to
Correct 0. In essence, an aspect-oriented weaver 11
0 inlines the desired aspect code in the class. This results in a highly optimized weave cord (w
an open code) is obtained.

Referring to FIG. 1, one or more high level programming elements 120 are provided in an aspect oriented weaver 110 of a general aspect oriented programming language environment 100.
Is shown entered. In the first stage, the aspect-oriented weaver 110 produces a woven or blended code. One of the high-level computer programming elements 120, as shown in FIG.
Programming block 122 from variable 12
3 and one or more processes or methods 124 that act on one or more of the variables 123. The aspect-oriented weaver 110 then examines the programming block 122 and determines where one or more variables 123 overlap within one or more of the various processes 124 of the programming block 122. Then aspect-oriented weaver 110
Combines, or "weaves," the code into a mixed source code block 130.

The second stage of the weaving process compiles the combined or interwoven program code blocks 130 into one or more executable modules 140. As shown in FIG. 1, in this second stage, the aspect-oriented weaver 110 uses the woven code block 1
Take one of thirty. Aspect-oriented weaver 11
0 sets the woven variables 131 and the woven process 133 of this woven code block 130 to 1
Compile into one or more executable modules 140.

In various exemplary embodiments, the systems and methods according to this invention are described by Ableson, Sussman, and Sussman in “The Structure and In”.
termination of Computer
It works for languages based on lambda algorithm, such as the Scheme language described in "Programs". In this language, the basic operations are function generation and function application.
The function is generated by a lambda expression, which is usually "lambda
(Var *) exp ”. For example, the expression "la
mbda (xy) (+ (* 2x) y) "defines a function that doubles its first argument and then adds the doubled first argument to its second argument. The "exp" part is called the body of the lambda expression, and the "var *" part is called its argument. The function is applied by an application formula of the form "fnarg *", where "fn" refers to the function to be applied and "arg *" is an argument. The "fn" part may be a lambda expression or any expression that evaluates a function. The calculation continues by reducing the application of the lambda equation. Simplifying lambda expressions is generally
By substituting those arguments for the appearance of those variables.

Programming languages are built around the idea of expression values. A program module essentially executes by converting an expression into a value. Values can be rotated in sequence during the execution of a program module, but expressions cannot. Variables are not bound to expressions that produce values,
You are bound to these values. After the expression is evaluated, the variable is bound and subsequent references to the variable can only access the value.

However, in the present invention, in aspect-oriented programming, not only the determined or calculated value, but some other emerging entity that is related to how the value is calculated or determined is a critical element of information. I have found that there are cases. Providing a function with only the values of the function's arguments is not always sufficient, as some emerging entities that are discarded by the value abstraction may be critical information.

There is a need for a programming language or programming language environment that stores only just the right kind of information about a program block and simplifies the rest of the information about that program block.
Of course, according to the invention, the "just right" will depend on what program element is using the information. When more information is needed than just values, the system, method, and aspect-oriented programming environment according to the present invention should provide only the information needed.

When evaluating an expression, sometimes we want only the value, but sometimes we need more information. For example, sometimes we want only the array that is the result of a loop, and sometimes it is important to know that the array is the result of a particular loop or function. In other words, an expression may mean an array or more than just an array. In the system, method, and programming environment according to the present invention, each of these possible meanings is represented by a significance of the expression.
e). The value of the expression is the least informative meaning. Any other significance will capture more information than is captured by value.

A programming system according to the invention,
Methods, and programming environments, transform the notion of meaning into something that computations can act upon. In the programming system, method, and programming environment according to the present invention, a computational process can be thought of as simplifying an expression to a canonical representation of its meaning. Naturally, an efficient implementation avoids explicitly constructing each intermediate expression, but the work done by such an implementation is similar to working between successive intermediate expressions.

Each step of the calculation is useful because it preserves the resulting final meaning. If there are differences between the two meanings, the two meanings will not allow the same simplification step.

The present invention recognizes that the difference between any two meanings lies only in which computational simplification steps are allowed by these two meanings.
And realize programming environment. This means that determining the significance of an expression is equivalent to performing the computational simplification permitted by that significance. Moreover, if some of the meanings are ordered from more informative to less informative, then these meanings can be determined in order. This first performs the simplifications allowed by the most informative significance, and then the simplifications permitted by the more informative meaning,
The same shall apply hereinafter.

It is desirable that each individually written library be able to introduce its own meanings and use these introduced meanings in the program, so there is no need for a total order for all meanings. I want you to understand. As a result, every significance has a corresponding processing step. Therefore, the calculation corresponds to simplifying the equation through successive steps, each step being
A canonical representation of an expression for one of its serial significance.

The system, method, and programming environment in accordance with the present invention also provide language constructs that specify which simplifications should be made for which meaning, as well as accessing information that is available in that sense. I need. In addition, determining which simplifications to make involves determining which function calls to expand. As described below, the system and method according to the present invention introduces a programming form that specifies at which stage the function should be reduced. In essence, lambda expressions behave like data objects until they are reduced. When reduced, the lambda expression behaves like a function.

On the other hand, the additional information provided by the semantics is included in the unreduced function call. This information is accessed in a form that allows the program to test whether the significance of the expression is the application of a particular function. The meaning of an expression behaves like that of the accessor to the data of the function.

Since the significance of a formula is a step towards the determination of the value of the formula, the significance always contains at least as much information as the value.
However, there may be applications for other information about the formula that is not directed towards determining the value of the formula. To support this, the system, method, and programming environment according to the present invention use projections to encapsulate such information. Projections are defined relative to meaning and provide additional information, usually regarding the role of that meaning in the rest of a given calculation.
The result of the projection can be a value. However, the result can also be meaningful at some stage in the projection. This means that the projection can remember a piece of calculation that can later be incorporated into the total calculation.

The significance of an expression is basically local to that expression, but projections, in contrast, reflect the role of expressions in larger calculations. This means that the projection is calculated using a technique similar to flow analysis. To support this, the system, method and programming environment according to the present invention provide a mechanism called a "propagator". The propagator is
Performed for each matching significance and inspecting and updating one or more projections of such matching significance and arguments of such matching significance.

The propagator is capable of both upward and downward data flow. The upward propagator examines the argument projection and updates the projection for the entire expression. In contrast, a down-propagator examines the projection of a given expression and updates the argument projection.

As the propagator performs the update, it exposes the meaning of the identification embedded within the particular meaning. When a propagator updates a projection of a given meaning, this update is only visible to other references to the same meaning. Since propagators are defined for meaning, identification of meaning is a problem.

As shown in FIG. 2, in the system, method, and programming environment according to the present invention, the weaving process proceeds through several stages. Although a given program element is simplified through successive semantic steps, many of these steps occur at compile time. Different degrees of processing are represented by different stages,
The simplest weaving only produces two stages, a first stage and a final stage.

As shown in FIG. 2, in various exemplary embodiments, the first stage is the syntax stage 210. This syntax stage 2
At 10, local information from a given high level code block 122 has not been discarded and context information is unavailable. This is this high level code
Corresponds to the original syntax of block 122. In the system, method, and aspect-oriented programming environment according to the present invention, the aspect-oriented weaver 110 is
"Weave" syntax step 210 from code block 122. The syntax step 210 is the weave code block 22.
Including 0. The syntax stage 210 then outputs the weave code block 220 generated in the syntax stage 210 to the next intermediate stage 230. The next intermediate stage 230 is the weaving code block 2 by the aspect-oriented weaver 110.
Woven from 20. Each stage 210, 230, 25
After 0, 270, one or more propagators defined in the weave code block 220, 240, or 260 corresponding to the step 210, 230, or 250 are executed to that step 210, 230, or 250.
The projection defined by is determined. Then
These projections follow the subsequent steps 230, 25.
0 and 270 respectively.

As shown in FIG. 2, after the first stage 210 is woven, the first intermediate stage 230 is woven.
This leads to further optimization of the program code contained in the high level code block 122. As before, the weave code block 240 of this first intermediate stage 230 is input to the next intermediate stage. This is repeated until the last intermediate stage 250 receives the weave cord block 245 from the previous intermediate stage (not shown).

As shown in FIG. 2, the final intermediate stage 250
This completes all optimized weaving. The weave code block 26 output from this last intermediate stage 250.
0 is input to the final weaving stage 270. It should be appreciated that the final weaving stage 270 is often a processed value stage. The weaving code 280 output from the final weaving step 270 is then executed by the executable program
Compiled into modules or a set of executable program modules.

When the expression is not reduced to a value,
When the system, method, and programming environment according to the present invention need to know whether the application of the expression should be reduced, the system, method, and programming environment according to the present invention should not reduce the expression during the current stage. It is estimated that

In order for the propagator to run completely,
The propagator maintains a distance relationship with the program or program element set while the program or program element set is in an intermediate stage. A propagator is a program or set of program elements that
You will have variables bound to meaning. However, propagators can only use these variables in a constrained manner. Initially, the propagator is logically executed until the propagator operates, but the bindings of these variables are inaccessible. That is, such variables are essentially treated as unbound variables. From the program or set of program elements, each variable is then bound to the appropriate meaning and the propagator ends execution. However, propagators generally cannot demand later meaning for variables bound to a program or set of program elements. If you try to access later meanings, you will still see such variables as unbound. To allow the propagator to output the resulting meaning, the propagator can use a special form described below to enclose code that should not be oversimplified beyond what the propagator is accessing.

Suppose a programmer wants to write code that performs various operations on an array. Typically, the programmer will write code that loops over each array to produce a new array. The programmer defines routines that perform various primitive operations and then builds high level operations that use the defined primitive operations. Programmers often use the output array of one routine as the input array of another. In this case, the programmer would like to use a fused loop to perform the join operation. This cannot be done with ordinary functional programming. I mean,
This is because the first operation must be executed before the second operation can be executed. Some optimizers will automatically perform loop fusion, but optimizers are usually ambiguous. Thus, in various exemplary embodiments, the systems, methods, and programming environments outlined above can be used to generate a library of primitive operations. In this library we know how operations merge with each other,
Fusion occurs when the routines are used in combination. Thus, in various exemplary embodiments, the systems, methods, and programming environments outlined above allow a library programmer to define routines to fuse together.

In various exemplary embodiments, the systems, methods, and programming environments outlined above allow loop fusion by asking which features a library routine requires at a minimum to be able to perform loop fusion. Can be applied to. Generally speaking, a potential loop is: "If your input is to be computed by a loop, give the internal operations of that loop and the array on which it worked. Should be used in my loop. ” An example of such pseudo-code is as follows: (define pointwise (lambda (fn arg) (case arg ((ptw-loop inner-fn inner-arg) (inner-fn inner-arg) (ptw-loop (lambda (x) (fn (inner-fn x)) ) inner-arg)) (else (ptw-loop fn arg)))))

Here, "pointwise" is a function that maps a function over the array, but "pointwise" is
ntwise "knows about loop fusion. This case format is "(ptw-loop inner-
fn inner-arg), the expression "ar
Is "g" calculated? "they said. The syntax "(inner-fn inner-arg)" is "i" for the pattern constant "ptw-loop".
It indicates that "nner-fn" and "inner-arg" are pattern variables. If the arguments match,
The function of the inner loop should consist of the functions from "pointwise". In this case, a single loop should be implemented using the constructed function. If not, use a simple loop. Specifically, "ptw-loop" can be defined as shown below to implement the actual loop.

If the following library code is used with an expression, the implementation of "double-plus" is:
There should be a single loop that doubles each element and then adds 1.

The key to the definition of "pointwise" is the case statement meaning "...
"It will be" in "Is g calculated?"
Is. In this case we need to test the loop that would have computed the arguments. Specifically, "point
The "wise" wants to see through the superficial structure of its argument the information of interest computed by the loop, without ever looking at the resulting array.

Therefore, "pointwise" is
It needs to be something between a function and a macro. Specifically, a "pointwise" needs to have its arguments partially processed so that it can see the information of interest. However, "pointwi
When the argument of “se” is completely evaluated, “pointwi
"pointwise" does not want to do so, as it leads to the removal of exactly that information of interest to "se". Thus, in various exemplary embodiments, the systems, methods, and programming environments according to the present invention outlined above are aware of the processing levels between these extremes and provide access to those recognized processing levels.

In the following, the basic forms, statements and / or constructs, of the system, method and programming environment according to the invention will be shown. The general form of a "case" statement for systems, methods, and programming environments according to this invention is as follows. case stage value (model (var *) exp *) * [( else exp)]

In the "case" statement, each model is an expression. The variable is released in the model,
It is bound in the formula. The values are compared with each model in succession. In the first model that matches the value, the expression is selected as the case value. The expression can access variables in the model, which are bound to form a match.

The comparison is made logically between the value of the specified significance and the model. The comparison is not done after the specified processing stage. Also, the simplification of the formula is done slowly.

The "if" statement shown below is equivalent to the statement "case value exp1 (nil () exp3) (else
provide additional syntax structure for exp2)) ".

If exp1 exp2 exp3 The "destruct" statement shown below is the statement "case stage value (model (var *)
exp *) (else (error)) ". deconstruct stage value model (var *) exp *

The statement "reductions
“Tage” specifies that the invocation of the value of “exp” should be reduced at the specified stage. reduction-stage stage exp

The apply statement indicates that the body of the function is reduced when it reaches its reduction stage. This statement has no keywords, but just the function "f
n ”. fn exp *

The "lambda" statement defines the following function: lambda (var * [.var] [=> var]) exp *

The form "=>var" is used to bind the represented variable to the result of the defined function.

The statement "stage" declares a stage and defines that the declared stage is after a given stage. stage name [: below stage]

Statement "projection"
Declares a projection that provides information about the stage. projection name: depends-on stage

The statement "propagator"
Works to declare a function that creates a propagator. propagator stage [: bottom-up |: top-down] function

In general, the propagator will look at the projections of some terms and update others. The behavior of the projector is assumed to depend on the projections that the propagator has examined, but not updated. If these projections are modified by another propagator operating at this stage, this propagator will be rerun. ": Bottom-up"
And the ": top-down" hints identify the most efficient order in which to execute the propagator to minimize the need for recomputation.

The terms seen by the propagator are lambda definition, lambda variable, application, and case form. If the lambda expression is reduced, the propagator will see the result of the reduction. This effectively turns the program tree into a directed graph. Specifically, at each point in the lambda body that referenced the lambda variable, the actual argument is
All will be shared among those that used variables. It should be understood from the propagator that there are no variables bound to meaning, only meaning.

The statement "update" defines a form that may appear only during the execution of the propagator. update old new

This statement updates the value of "old" with the value of "new" which should evaluate the term projection at the stage where the propagator is applied.

The statement "same request"
"ncy" defines a format that can occur only during the execution of the propagator. same-frequency exp

This statement returns true if the frequency of expression evaluation and the frequency of terms handled by the propagator are the same.

As an example of what this means, consider the following equation. (let ((x (+1 2))) (lambda (y) (* xy))

It should be appreciated that "let" commands or operations are expanded at the earliest processing stage. here,
One of the arguments of the multiplication term is an addition operation. Due to the intervening lambda, this addition operation will not be executed as many times as the multiplication operation. The propagator needs to be able to react to this. In addition, when the execution frequency is different, it occurs when a term in a case branch refers to a variable outside the case.

Another view is that since the propagator is executed before run time, one invocation of the propagator may correspond to many invocations that it makes sense to handle. This is not a problem as long as all the subordinate terms processed by the propagator are called once per invocation of the main term. But, as the example shows, this is not always the case. Propagators need to be careful when updating information related to different frequency implications. "Sam
The "e frequency" statement provides a way for the propagator to detect this situation.

3-5 show sample code segments for performing loop fusion. This sample code deals with many, but not all, cases where the results of one loop are used by some other loops.

Lines 1 to 3 describe various information that the flow process can act upon. This information includes three different meanings for expressions and unique identifiers for terms at the least level of simplification. Line 2 defines the key to get this value from the hash table. Line 3 defines a loop that will probably calculate this value among other things. To allow sharing, the projection defined in line 3 will hold the loop for only one of the values calculated by this loop. Projections to other values are (loop-referencevalue) for some other value calculated by this loop.
Will hold. Following this chain eventually leads to a value that holds this loop.

Lines 4-6 define the top level function. Lines 7- (end) are reduced pointwis
Define a subroutine library that defines the e operation. Line 8 allows for reduction of top-level lambda expressions, effectively and! Make the definition of a macro. Line 1
1 to 39 define propagators that decorate each format with a loop that calculates its value. When line 37 is executed, this indicates that this case is not "pointwise", and as noted, the output is needed. Lines 39-46 are the pointwis that calculate the value.
Returns a se loop. This involves making trivial loops if necessary. Rows 43 and 44 allow the reduction to be reduced after loop fusion. Lines 47-50 indicate to return the loop if the value was calculated by the loop. Lines 51-57 return a value with a computing-loop holding a loop for computing the arguments.
Rows 58-69 record this type of demand for results. Lines 70-79 indicate that the actual array for the argument is required.

In lines 80-100, the pointwise
The structure of the loop or "ptw-loop" is designed to facilitate fusion, including creating loops with multiple values. To allow this, the inputs and outputs are named with keys, so that the naming does not have to change under fusion. These keys are
Exists only during loop fusion. That is, these keys will be simplified away by runtime. In line 93, the statement "fn" takes a list of key / value pairs and an augmented list of key / value pairs for it. "Input" is a list of key / array pairs, including the IDs expected by "fn".
"Output" is a list of keys, these keys are f
n must be in the output key. Loop
Maps the function across the corresponding elements of the array and returns a list of key / array pairs with an entry for each key in the output ID. Lines 101-103 are the pointwise for returning the correct result from the loop that calculates the result, which was constructed by the propagator in the previous stage.
Define the operation.

Lines 104-117 are the two pointtws.
Combines the work of the ise loops and returns a loop that combines their inputs and outputs. Line 115 indicates that the internally defined function is reducible after loop fusion. Lines 118-125 presume that there is a key in the list of pairs and search for the key in the list. Line 119 indicates that this is done before runtime. Lines 126 and 127 show that the act of merging two lists is coded similarly to the act of finding an ID in the lists.

The basic operation of the weaver is as follows.
Start from the program. Simplify the program until all parts of the program have reached the first stage. Run the propagator for this stage to decorate the simplified program with projections. Then simplify the program a bit more until all parts of the program reach the next stage. During this simplification, the simplified program from the previous step and the decorations added by the propagator are the data that can be used to determine what the further simplified program looks like.
This process is repeated until the final stage of the program is reached. Each part of the program has significance at each stage. The question is whether or not any such part of the program must be reduced from one stage to the next so that the part justifies its significance at the next stage.

FIG. 6 illustrates an exemplary embodiment of the relationship between the stages shown in FIG. 2 during program compilation or weaving using the system, method, and programming environment according to the present invention. As shown in FIG.
A set 120 of one or more programming elements
Aspect-oriented weaver 110 to be compiled
Entered in. Aspect-oriented weaver 110 examines for common variables and operations in one or more sets 120 of programming elements and provides instructions 310 that condense one or more programming elements 120 to the proper meaning. As shown in FIG. 6, three meanings A, B, C are identified in the set 120 of one or more programming elements. The three implications A, B, and C are the first corresponding to the first stage 210 outlined above with respect to FIG.
It is incorporated into the first stage weave code block 320, which is generated as a result of the stage analysis.

Next, the aspect-oriented weaver 110
The projector 330 is invoked by sending a command along the inter-propagator visibility path 325. The projector 330 examines the first stage weave code block 320 to determine which of the meanings A, B, C can be updated during the next weave. For example, in the exemplary embodiment shown in FIG. 6, projector 330 identifies meanings A and B as updatable. Projector 330 spawns propagator 335 along projector / propagator path 327 to implement updates to meanings A and B, if any, in the future. The aspect-oriented weaver 110 then proceeds to the next weaving stage.

In the second weaving stage, the aspect-oriented weaver 110 uses the first stage weaving code block 320 as an input to the second stage or intermediate stage analysis, as outlined above with respect to FIG. The aspect-oriented weaver 110 examines the first stage weave code block 320 to identify any common variables and / or operations and sends instructions 332 that reduce the first stage weave code block 320 to the appropriate meaning. . As shown in FIG. 6, in the first stage weave code block 320, three meanings D, E, F are identified. Three meanings D, E, F
Is incorporated into the second stage weave code block 340, which is generated as a result of the second stage analysis corresponding to the intermediate stage 230 outlined above with respect to FIG.

Again, the aspect-oriented weaver 110 calls the projector 350 by sending a command along the inter-propagator visibility path 345. The projector 350 checks to see if there is any significance in the second stage weave code block 340 that may be brought about by future weaving. For example, in the exemplary embodiment shown in FIG. 6, projector 350 determines that significance E meets this criterion. Projector 350 uses projector / propagator path 347 to produce propagator 355 for significance E. Propagator 355 then communicates with propagator 335 using inter-propagator visibility path 337 to determine if there is something to update. In this particular example, they have no common significance. That is, it is meaningless to continue in both the first stage weave code block 320 and the second stage weave code block 340. Therefore no update is necessary.

Subsequently, in the third weaving stage, the aspect-oriented weaver 110 uses the second stage weaving code block 340 as an input to the final stage analysis. As described above, the aspect-oriented weaver 110 examines the second stage weave code block 340 to identify any common variables and / or operations and reduces the second stage weave code block 340 to an appropriate meaning. Instruction 34
Send 2. As shown in FIG. 6, the second stage weaving cord
In block 340, three senses A, G, H are identified. The three meanings A, G, H are generated as a result of the third stage analysis corresponding to the final stage 270 outlined above with respect to FIG. 2, the third stage weave code block 360.
Incorporated into.

Next, the aspect-oriented weaver 110
Calls the third projector 370 by sending a command along the interoperability path 365. Projector 370 determines that meanings A and H are updatable. Projector 370 provides propagator 375 for significance A and H to projector / propagator path 3
Produce along 67. Then the propagator 375
Communicate with the propagator 355 along an inter-propagator visibility path 357. Propagator 375 includes second stage code block 340 and third stage code block 36.
There is no common meaning with 0, and it is determined that updating is not necessary.

The propagator 375 also communicates with the propagator 335 along another inter-propagator visibility path 377, sharing the meaning A between the first stage weave code block 320 and the third stage weave code block 360. To determine. Then the propagator 375
Update all references to meaning A in first stage weave code block 320 and third stage weave code block 360. This ensures that the weaving code will be executed correctly later. As mentioned above, this process continues until all code is fully woven and thus fully optimized.

FIG. 7 illustrates the weaving process for the loop fusion example. Aspect-oriented weaver 110 provides instructions 410 to syntax stage 430 to read high level program code block 420. This high level program code block 420 is provided for use as the first stage code block in the first or syntactic stage 430 of the weaving process. The aspect-oriented weaver 110 then proceeds to the syntax stage 430.
The first stage code block 420 is examined to identify variables and operations that are common throughout the first stage code block 420. Aspect-oriented weaver 110 uses command 43
5 is used to control the syntax stage 430. In this example,
There are two intermediate stages between the syntax stage 430 and the final stage 480. The weave code block 440 output from the syntax stage 430 is input to the first intermediate stage 450, which in this exemplary embodiment may be referred to as the loop construction stage. .

Next, the aspect-oriented weaver 110
The first stage weave code block 440 is examined, and instructions 455 are provided to the loop construction stage 450. During the loop construction stage 450, the first stage code block 420
The candidate loop structure of the array calculated by the loop of is published. The loop construction stage outputs the second stage weave code block 460. Unfortunately, the value of a particular loop cannot be calculated directly from the loop structure stage 450 because the loop structure implements an explicit mapping function across the array. In this situation it is preferable to reduce the inner loop function before runtime. Therefore, it is necessary to transform the loop structure into a reduced loop. This transformation is realized by the calculation stage 470.

Next, the aspect-oriented weaver 110
Instructions 475 are provided to the calculation stage 470 to reduce the loop structure contained in the second stage weave code block 460. In response, calculation stage 470 outputs a third stage weave code block 480. This is the final stage, fully woven. This final stage code block 480 is also the value stage code block 48.
Also called 0. Then final stage code block 480
Is output to the compiler 490. Compiler 490
Compiles a fully interwoven value stage block 480 under control of the aspect-oriented weaver 110 via signal channel 495 to form an executable code block 500. Executable code block 500
Is output from the compiler 490.

The problem is that each time the library fuses a loop, it may need a new working execution of its argument loop. If the arguments are shared, then duplicate calculations occur. One solution to this
The first is to not fuse loops when arguments are shared. Another solution is to create a single loop that reflects all the usage of shared arguments.

If one of the above solutions is adopted,
It is necessary to know some information about how the arguments are used elsewhere in the program. That is, the library code needs to have access to some information about the wider context, not just its direct arguments. The library code needs some data flow information related to its arguments. This requires more language features.

To achieve a simpler answer, if the arguments are not shared if they are shared, the library code asks, "is the argument being passed to me used elsewhere?" Need to ask. It should be understood that this question cannot be answered at any stage simply by looking at the code that computes its argument. The answer to this question is not how the arguments are calculated, but how they are used. Furthermore, the answer to this question relies on the recognition of argument identification, ie what the same argument means to be used elsewhere.

Therefore, to support this,
In various exemplary embodiments, the systems, methods, and programming environments outlined above support the notion of term projection. The projection provides information about the section. This information is usually not available in the section itself, but in the context of its use. Thus, in various exemplary embodiments, the systems, methods, and programming environments outlined above introduce the aforementioned propagator as a separate construct to compute projection context information. A propagator is a format that can be matched to the appropriate stage terms and then published information about the projection of the term or sub-terms of the term. Initially, the projection value is set to the default, which means that the term is found in the empty context. As the propagator executes, the propagator fills the picture in context. Thus, the propagator operates to incrementally raise the bounds on the context of a term while being imperatively coded.

The following pseudo code calculates if a term is used more than once.

In order for this example to work, it is necessary to introduce a new stage, the operating stage, which is carried out before the loop fusion stage. "Doub," which is a combination of loops
Definitions such as "le" are reduced at this stage, which makes the use of loop results visible. In this way, long range flow analysis is not required. The only problem is the procedure that the programmer is interested in,
It is not necessary to follow one format through several procedures. The procedure that has access to the formal structure when determining the loop structure is the procedure that receives it directly.

However, this mechanism is also capable of performing long range flow analysis. This is done by accumulating information and propagating along the way. In fact, this mechanism is sufficient to represent a shared second approach, the generation of a single large fusion loop, as discussed above with respect to FIGS.

[Brief description of drawings]

FIG. 1 illustrates a conventional relationship between programming.

FIG. 2 is an exemplary embodiment of various degrees of processing represented by various stages of programming elements in a semantic-based aspect-oriented programming environment in accordance with the systems and methods of this invention.

FIG. 3 is an exemplary pseudo code listing of a program for achieving loop fusion using the systems and methods according to this invention (one pseudo code listing is shown in FIGS. 3-5).

FIG. 4 is an exemplary pseudo code listing of a program for achieving loop fusion using the systems and methods according to this invention (one pseudo code listing is shown in FIGS. 3-5).

FIG. 5 is an exemplary pseudo code listing of a program for achieving loop fusion using the systems and methods according to this invention (one pseudo code listing is shown in FIGS. 3-5).

FIG. 6 illustrates in more detail one exemplary embodiment of the relationship between the stages shown in FIG.

FIG. 7 illustrates an exemplary result of applying a semantic-based aspect-oriented programming environment to loop fusion operations according to the systems and methods of this invention.

[Explanation of symbols]

110 Aspect Oriented Weaver, 120 Programming Elements, 122 High Level Code Blocks, 21
0 syntax stage (first stage), 220, 240, 245,
260 weave cord block, 230 first intermediate stage, 250 last intermediate stage, 270 final weave stage, 320 first stage weave cord block, 32
5,337,345,377 Inter-propagator visibility path, 327,347,367 Projector / propagator path, 330,350,370 projector,
335, 355, 375 propagator, 340 second
Stage Woven Code Block, 360 Third Stage Woven Code Block, 365 Interoperability Path, 420 First Stage Code Block, 430 Syntax Stage, 450
First intermediate stage, loop construction stage, 440 first stage weave code block, 460 second stage weave code block, 470 calculation stage, 480 final stage code block, third stage weave code block, value stage code Blocks, 490 Compiler, 495 Signal Channels, 500 Executable Code Blocks.

Claims (2)

[Claims] 1. A method for simplifying a programming element that is compilable into instructions for operating a data processing device, the programming element having at least one portion, the method comprising: Determining all at least one propagator for the current simplified programming element by simplifying until all parts have reached the first phase, the programming being performed by the propagator. Associating at least one projection with a current simplified programming element using at least one propagator determined in the element; and the current simplified programming element and associated projections. To Based in part even without a simplified pre programming elements present stage, at least one portion is simplified until all reach the next stage,
Producing a next step simplified programming element. 2. A method of converting a programming element into a plurality of woven code blocks compilable into instructions for operating a data processing device, comprising: (a) at least one common variable and at least in the programming element. Identifying at least one of the one common process, and (b) programming element based on the identified at least one of the at least one common variable and the at least one common process. To at least one meaning, (c) incorporating at least one meaning into the first weaving code block, (d) incorporating the meaning that can be updated in a subsequent step of the method. Based on the step of determining 0, 1 or more, and (e) the result of the determination, the first weaving code block Invoking a propagator that can be used to perform any desired update to the determined updatable significance of the process, and repeating steps (a)-(e) at least once, resulting in the immediately preceding Producing a subsequent weave code block based on the weave code block, further comprising: (f) communicating with a propagator of at least one previously produced weave code block to produce the previously produced weave code block. Determining if any of the meanings of the at least one weave code block are common to the subsequent weave code block, and (g) at least one subsequent weave code block and at least one previously produced Two weaving cords
Updating any subsequent weaving code blocks and the at least one previously produced weaving code block in the block, if they have a common meaning.