Directives and Built-in Functions (Target Language Compiler)

Target Language Compiler

Object-Oriented Facility for Generating Target Code

The Target Language Compiler provides a simple object-oriented facility. The language directives are

%language string
%generatefile
%implements

This facility was designed specifically for customizing the code for Simulink blocks, but can be used for other purposes as well.

%language

The %language directive specifies the target language being generated. It is required as a consistency check to ensure that the correct implementation files are found for the language being generated. The %language directive must appear prior to the first GENERATE or GENERATE_TYPE built-in function call. %language specifies the language as a string. For example,

```
%language "C"
```

All blocks in Simulink have a Type parameter. This parameter is a string that specifies the type of the block, e.g., "Sin" or "Gain". The object-oriented facility uses this type to search the path for a file that implements the correct block. By default the name of the file is the Type of the block with .tlc appended, so for example, if the Type is "Sin" the Compiler would search for "Sin.tlc" along the path. You can override this default filename using the %generatefile directive to specify the filename that you want to use to replace the default filename. For example,

```
%generatefile "Sin" "sin_wave.tlc"
```

The files that implement the block-specific code must contain a %implements directive indicating both the type and the language being implemented. The Target Language Compiler will produce an error if the %implements directive does not match as expected. For example,

```
%implements "Sin" "Pascal"
```

causes an error if the initial language choice was C.

You can use a single file to implement more than one target language by specifying the desired languages in a vector. For example,

```
%implements "Sin" "C"
```

Finally, you can implement several types using the wildcard (*) for the type field:

```
%implements * "C"
```

Note The use of the wildcard (*) is not recommended because it relaxes error checking for the %implements directive.

GENERATE and GENERATE_TYPE Functions

The Target Language Compiler has two built-in functions that dispatch object-oriented calls, GENERATE and GENERATE_TYPE. You can call any function appearing in an implementation file (from outside the specified file) only by using the GENERATE and GENERATE_TYPE special functions.

GENERATE. The GENERATE function takes two or more input arguments. The first argument must be a valid scope and the second a string containing the name of the function to call. The GENERATE function passes the first block argument and any additional arguments specified to the function being called. The return argument is the value (if any) returned from the function being called. Note that the Compiler automatically "scopes" or adds the first argument to the list of scopes searched as if it appears on a %with directive line. (See Variable Scoping.) This scope is removed when the function returns.

GENERATE_TYPE. The GENERATE_TYPE function takes three or more input arguments. It handles the first two arguments identically to the GENERATE function call. The third argument is the type; the type specified in the Simulink block is ignored. This facility is used to handle S-function code generation by the Real-Time Workshop. That is, the block type is S-function, but the Target Language Compiler generates it as the specific S-function specified by GENERATE_TYPE. For example,

GENERATE_TYPE(block, "Output", "dp_read")

specifies that S-function block is of type dp_read.

The block argument and any additional arguments are passed to the function being called. Similar to the GENERATE built-in function, the Compiler automatically scopes the first argument before the GENERATE_TYPE function is entered and then removes the scope on return.

Within the file containing %implements, function calls are looked up first within the file and then in the global scope. This makes it possible to have hidden helper functions used exclusively by the current object.

Note It is not an error for the GENERATE and GENERATE_TYPE directives to find no matching functions. This is to prevent requiring empty specifications for all aspects of block code generation. Use the GENERATE_FUNCTION_EXISTS or GENERATE_TYPE_FUNCTION_EXISTS directives to determine if the specified function actually exists.

Multiple Inclusion Output File Control