Code Generation Node

This node contains the following options:

Protected against division by zero

If this option is activated, ASCET generates a check to prevent division by zero at runtime. If the denominator is non-zero, the division is evaluated normally. If the denominator is zero, then, by default, the nominator is returned as result (i.e. a/b == a if b == 0).

The default result for a zero denominator can be modified via the Result on Division by Zero option.

This does not apply to integer divisions with arithmetic services, because arithmetic services routines are required to protect against division by 0.

The calculation of a remainder involves an implicit division. Activating the Protected against Division by Zero option protects the calculation of remainders from a zero divisor.

This option entails a performance penalty, so it should be deactivated to achieve maximum code efficiency.

Result on Division by Zero

When ASCET generates code to protect against division by 0 (activated via the Protected against Division by Zero option), this combo box determines the behavior upon division by zero.

If you select numerator (default), the numerator, limited to [value_range_min, value_range_max], is returned as result.

If you select user defined, a call to the user-defined C macro protDiv0(num, value_range_min, value_range_max) is returned. This macro has to be specified in one of the included header files.

The macro arguments have the following meaning:

• num – the current numerator value
• value_range_min – the lower boundary of the value range calculated by ASCET for the division
• value_range_max – the upper boundary of the value range calculated by ASCET for the division

The second and third argument are used – in that order – to use the minimum and maximum of the value range of the division result. It is possible, for example, to provide the macro

#define protDiv0(num,min,max) (num<0?min:max)

to get, depending on the result data type, the largest, or smallest, possible integer value.

Protected Division against Signed Overflow

A signed overflow on a division occurs if the numerator value -2147483648 is divided by -1: the resulting value 2147483648 cannot be represented in a signed type, therefore, it overflows.

When this option is activated, divisions that might lead to a signed overflow at runtime are embedded, by the code generator, in a conditional operator that checks numerator and denominator of the division and – if necessary – uses the maximum value that can be represented by a signed type as division result.

This does not apply to integer divisions with arithmetic services, because arithmetic services routines are required to protect against signed overflow.

The calculation of a remainder involves an implicit division. Activating the Protected Division against Signed Overflow option also protects the calculation of remainders from signed overflow.

Protected Vector Indices

For the implementation experiment or object-based controller implementation, a warning of type WIle77 is issued when the code generator considers the index values of an array or matrix to be in danger of over- or underflow at runtime.

If the Protected Vector Indices option is deactivated, the warning reads as follows:

index <%1> possibly out of bounds for indexed expression "%2" – will not be limited

If the Protected Vector Indices option is activated, the protection is implemented as a limitation of the index values. The warning now reads:

index <%1> possibly out of bounds for indexed expression "%2" – will be limited

If the array or matrix uses system constants to determine its size (see Variant Size for Arrays and Matrices), Protected Vector Indices uses the value of the system constant.

If the array or matrix uses variable size (see Variable Size for Arrays and Matrices), Protected Vector Indices uses the actual size.

Use Redundant Data Storage

This option allows to activate/deactivate redundant data storage for all elements marked as redundant. See also Redundant Data Storage.

Generation of Enums

This options controls how enumeration values are written to the generated code.

• Literal: The integer values corresponding to the enum values are written in the generated code. This avoids name clashes, but is not readable.

  This is the default setting.

  When you open or import a project from an ASCET version that used the Boolean option Generate Define Directives for Enum Values, the old value false is interpreted as Literal.

• Define: Preprocessor #define directives are generated for all values of all enumeration types that are used in a component. For enumerators named Red and Green, the #define directives read as follows:

  #define Red 0

  #define Green 1

  The names of the enumerators appear in the generated code.

  This is readable, but comes with the restriction that two enumeration types cannot use enumerators with identical names. If two enumerations visible in your project have identical enumerators, an error MMdl19 is issued during code generation.

  When you open or import a project from an ASCET version that used the Boolean option Generate Define Directives for Enum Values, the old value true is interpreted as Define.

• Enumeration: For each enumeration type used in the project and its components, a type definition containing a C enumeration type definition is created. The labels inside this type are generated according to the pattern in the target options, which by default includes the enumeration type name and the enumerator name. All enumerators are specified with a value to be compliant with MISRA-C:2012 rule 8.12.

  EXAMPLE

  The enumeration type Enum_type is used in Module_BDE, which is used in Project. The following type definition is generated: /************************************************** * BEGIN: Type definitions *------------------------------------------------*/ enum Enum_type {   Enum_type_enumerator01 = 0U,   Enum_type_enumerator02 = 1U,   Enum_type_enumerator03 = 2U }; The following C code is generated for the block diagram functionality (ANSI-C target, GENERIC-OSEK operating system): _enum_Var = ENUM_TYPE_enumerator01; _array_enum[_in_array] = _enum_Var; msg_enum__MODULE_BDE_IMPL_process = _array_enum[_out_array];

  The location of the type definition depends on the Header/C Code Structure selected in the Build options.

  Header/C Code Structure	location of type definitions
  Component	A separate header file <enum_name>M.h with the type definition is created for each enumeration.
  Project	The type definitions for the enumerations are included in the single header file.
  Project Header and Source
  Project Header and Source+External C Code

When you export a project to an AMD format V6.4.4 or older, or when you open an old project, the settings are transformed to the old option as follows.

Add Comment with Implementation Information for each Assignment Statement

When this option is activated, a comment is generated in front of each assignment or return statement. This comment contains implementation information on the right-hand side of the assignment.

EXAMPLE
/* return with expr from doAddition:      min=-65536, max=65534, hex=1phys+0,      limit=(maxBitLength: true, assign: true)*/ return ((sint32)input1 + input2);

Add Comment with Specification Source for each Statement

When this option is activated, a comment is generated in front of each generated assignment. The comment contains the specification source of the assignment.

ESDL: line number

Block diagram: sequence call number

State machine: name of action/condition and respective state/transition

EXAMPLE (ESDL)
/* doAddition: line #1 */ self->cont->val = input1 + input2;

Add Comment with Generation Information for each Component

When this option is activated, comments are created at the beginning of the generated code for each component. The first comment contains information regarding the component and ASCET, the second contains all build and experiment/production code options.

Example: Comment with Generation Information for a Component

Allow References without Init Value

When this option is activated, it is possible to generate code for explicit references without intialization.

See also Initialization of Explicit References.

Expand names in #if in C Code Components

If this option is enabled, ASCET treats #if and #elif preprocessor directives in C code components like normal C code. This means that ASCET substitutes names of variables, constants, system constants, enumerations, etc.

Other preprocessor directives are kept as they are, especially #define.

Preprocess Internal Headers

If this option is enabled, ASCET perform name substitution and preprocessing also for the internal header of each C code component.

Prefix for Component Names

Inserts a character string as prefix for the component names in the generated code.

Casting

Allows the selection of a casting strategy. Available selections are MISRA compliant andTarget Optimized. The default selection is MISRA compliant.

The Arithmetic Services casting is no longer available.

See also

Component Manager – Promoting Messages

Variant Size for Arrays and Matrices

Variable Size for Arrays and Matrices

Redundant Data Storage

Comment with Generation Information for a Component

Initialization of Explicit References

MISRA Compliant

Target Optimized