Background

Use Case

The ATL language semantics defines operations on models (such as testing condition on an element, creating an element or setting an element feature to a value). These operations are implemented by the ATL VM which executes ASM program on source model(s) to produce the output model(s).

Getting the compiled ASM version of an ATL transformation is done in three stages:

injecting ATL source code to get it into a model based representation (XMI whose structure conforms to the ATL model)

transform this ATL model into an ASM model

extracting the ASM model to get it into a textual representation conforming to its syntax (ASM code).

The second stage is actually done by a transformation in ACG defined in ATL.acg.

This process has been bootstrapped. This means that ACG semantic is defined in ACG. Thus an ACG script is now compiled using ACG to get the corresponding ASM version. This means that the compilation from a transformation model to ATL VM code is done by the ATL VM itself using ACG.acg.

Every transformation defines an entry point (with the keyword startsWith). It is a production rule called at the beginning of the transformation. It defines thereby the top level element of the transformation.

Templates

The elements used to express the transformation are the templates. sThey are the code production rules defined in the context of an element of the transformation language model. They define what code should be generated for this kind of item.
Rule execution may be limited to only several elements of the kind satisfying a given condition. The condition can be entered after the pipe symbol.

This is a production rule defined from the object Helper which carries out only one operation (analyze). Accordingly, the production rule will be called corresponding to the property feature of the property definition of the current Helper model element

Functions

Functions are used as a programming facility. Like in an object oriented language, functions are assigned to model elements and have access to all properties of that model element. They provide the means to easily request derived information from a model element, like the following example shows.

This statement is defined in the context of an object having a multi-valued feature named parameters, of which only the only which property kind is equal to 'in' are filtered using the OCL select function. For each one of these parameters a param instruction is called with arguments:

the varName feature of the parameters component in question

the string “J”

In one of the following sections it is explained how the param keyword is used in conjunction with an operation and what effects its parameters actually have.

Only Once Evaluation Statement

The corresponding rules will be evaluated only once. If it is defined inside a Foreach statement, the evaluation will be done after the last loop executed and is then inserted into the resulting assembly from the loop. This is useful for blocks interweaving.

Analyze statement

Call the matching template for the model element(s) resulting from the OCL evaluation in the current context. Between braces we can put the production code that should be executed after each temple calling (not used in example).

From within the current object, this will fetch the object pointed by the inPattern reference, and then will follow its filter reference to get the object which will lead in the launch of the production rule corresponding to the objects type.

Offsets management

The procedural style of ACG (defining templates as units of processing) leaves the replacing of a template call by corresponding code to the compiler. This results in a lack of a priori knowledge of the amount of code generated by an analyze statement and thereby in the difficulty to handle code offsets (needed by some instructions of the ATL VM). To fix this difficulty, ACG provides a mechanism of labels.

Definition:

<label name>:

This way, the ACG compilation replaces any argument of jump instructions referencing a label by the correct offset. Of course, no trace of label is left in the ASM code.

This code starts with an analyze statement followed by a if statement. We can assume that the result of the evaluation of self.condition will lead to instructions pushing their result (a boolean) on the stack. The if statement will ask an evaluation of this variable and will make the execution continue at a point depending on the result. If there is true on the top of the stack, the execution pointer will jump over the instructions produced by the production rules before thn:. Otherwise it will continue on the next line. The goto statement will always make the exevution pointer jump to the location of the eoi: label.

Inside foreachstatements a parameter can begiven to the label, so the compiler knows it should recalculate the offset for each iteration.
Example:

Here we would find jumps inside the production code of the foreach loop that act as forward/continue statements. Without the extra parameter the offset will be calculated only once and later iterations will jump backward, possibly creating infinite loops

Simple code factoring

The let statement allows a programmer to write an OCL expression only and use it several times. The resulting value is bound to a literal. This way, anywhere inside the let statement scope, the compiler will replace this literal by the corresponding OCL expression.

The outer brackets define the let statement scope (the code in which ep will be recognized). The code inside uses this binding resulting in a clearer and smarter code.

Code generation units

Templates

Templates can be assigned call condition which allows to define several behaviours for a single type depending on a condition.

When an analyze statement is found, a template defined for the element true type is called.
If there exists conditional templates, the conditions are evaluated within the context of the element analysed. As conditions must define a partition of candidate model elements, at most one conditional template can be called.
In case that no conditional template is defined or no condition is matched, the default template (the one with no condition call on it) is called.

Functions

Functions can be called on model elements if they are of the type (or a subtype of) of the function context.
A function defined on type foo, named bar and with no parameter would be called this way:

param

This is the definition of an operation called resolveTemp on the ATL context module with two parameters (an Object value and a String name).

variable

Allocates a slot in the operation. The scope of the the variable is defined by the brackets. It also calls a store instruction at its place (the result is an immediate initialization of the variable with the value on the top of the stack (popped).

Definition:

variable <identifier> name <variable name> {
<Produced code definition for which the variable is defined>
}

The variable instruction needs an identifier as the name is not restrictive enough. Indeed, several variable with the same name can coexists in the same code scope.

VM Instructions

There exists one statement per ATL VM instruction. Each of these statements have the same name than the instruction and, of course, leads to the production of this instruction in the target model.

An instruction is followed by its operand as defined in the VM specification. For some arguments defined is ACG, the compiler performs a rewriting (or more exactly an interpretation -read transformation) given that that ASM code is not convenient to write by hand and that ACG could help by making things more "human compliant".
It is the case for :

the load instruction: Its argument is a variable reference. In ACG, this reference is:

their identifier for common variables

their name for parameters.

→ It is rewritten in corresponding slot number.

the if instruction: Its argument is a code offset.

→ It is replaced by the absolute position of where the referred label should have been if it had not been removed.

the goto instruction

→ Same rewritting

Use

Once the ACG file is defined for the transformation language model, it has to be compiled so that every transformations written is this language could be compiled into ASM.

This is done thanks to an AMMA tool set including several Ant scripts. Those scripts are intended to provide all the facilities to build a Domain Specific Language (editor, megamodel, concrete and abstract syntax and a compiler if the semantics relies on the ATL VM).