What Is Code Replacement?

Code replacement is a technique to change the code that the code generator produces for functions and operators to meet application code requirements. For example, you can replace generated code to meet requirements such as:

• Optimization for a specific run-time environment, including, but not limited to, specific target hardware.

• Integration with existing application code.

• Compliance with a standard, such as AUTOSAR.

• Modification of code behavior, such as enabling or disabling nonfinite or inline support.

• Application- or project-specific code requirements, such as:

  • Elimination of math.h.

  • Elimination of system header files.

  • Elimination of calls to memcpy or memset.

  • Use of BLAS.

  • Use of a specific BLAS.

To apply this technique, configure the code generator to apply a code replacement library (CRL) during code generation. By default, the code generator does not apply a code replacement library. You can choose from libraries that MathWorks^® provides and that you create and register by using the Embedded Coder^® product. The list of available libraries depends on:

• Installed support packages.

• System target file, language, language standard, and device vendor configuration.

• Whether you have created and registered libraries, using the Embedded Coder product.

Libraries that include GNU99 extensions are intended for use with the GCC compiler. If you use one of those libraries with another compiler, generated code might not compile.

Code Replacement Libraries

A code replacement library consists of one or more code replacement tables that specify application-specific implementations of functions and operators. For example, a library for a specific embedded processor specifies function and operator replacements that optimize generated code for that processor.

A code replacement table contains one or more code replacement entries, with each entry representing a potential replacement for a function or operator. Each entry maps a conceptual representation of a function or operator to an implementation representation and priority.

Table Entry Component	Description
Conceptual representation	Identifies the table entry and contains match criteria for the code generator. Consists of: Function name or a key. The function name identifies most functions. For operators and some functions, a series of characters, called a key identifies a function or operator. For example, function name 'cos' and operator key 'RTW_OP_ADD'. Conceptual arguments, which represent input or output arguments for a function or operator being replaced. Conceptual arguments observe code generator naming ('y1', 'u1', 'u2', ...), with corresponding I/O types (output or input) and data types. Other attributes, such as an algorithm, fixed-point saturation, and rounding modes, which identify matching criteria for the function or operator.
Implementation representation	Specifies replacement code. Consists of: Function name. For example, 'cos_dbl' or 'u8_add_u8_u8'. Implementation arguments, which represent an input or output arguments for a C or C++ replacement function. Implementation arguments observe C/C++ name and data type specifications that match the corresponding I/O types (output or input) and data types. Parameters that provide additional implementation details, such as header and source file names and paths of build resources.
Priority	Defines the entry priority relative to other entries in the table. The value can range from 0 to 100, with 0 being the highest priority. If multiple entries have the same priority, the code generator uses the first match with that priority.

When the code generator looks for a match in a code replacement library, it creates and populates a call site object with the function or operator conceptual representation. If a match exists, the code generator uses the matched code replacement entry populated with the implementation representation and uses it to generate code.

The code generator searches the tables in a code replacement library for a match in the order that the tables appear in the library. If the code generator finds multiple matches within a table, the priority determines the match. The code generator uses a higher-priority entry over a similar entry with a lower priority.

Code Replacement Limitations

Code replacement verification — It is possible that code replacement behaves differently than you expect. For example, intermediate data types for a Simulink^® block might not match the intermediate data types used by your implementation code even if the input and output data types do match the implementation code. Additionally, discrepancies can occur due to implementation details of the replacement code, as the implementations might differ from the logic used by Simulink for simulation. This can lead to mismatches between simulation and generated code behavior. Verify code replacements by examining the generated code and check the implementations when potential mismatches occur between simulation and generated code behavior to justify the discrepancies.

Code replacement for matrices — Code replacement libraries do not support Dynamic and Symbolic sized matrices.