Documentation |
On this page… |
---|
When Integer Overflow Can Occur Support for Handling Integer Overflow in Charts |
For some arithmetic operations, a processor might need to take an n-bit fixed-point value and store it in m bits, where m ≠ n. If m < n, the reduced range of the value can cause an overflow for an arithmetic operation. Some processors identify this overflow as Inf or NaN. Other processors, especially digital signal processors (DSPs), handle overflows by saturating or wrapping the value.
For more information about saturation and wrapping for integer overflow, see What Are Saturation and Wrapping? in the Fixed-Point Designer™ documentation.
For charts, you can control whether or not saturation occurs for integer overflow. Use the chart property, Saturate on integer overflow, to control overflow handling.
Check Box | When to Use This Setting | Overflow Handling | Example of the Result |
---|---|---|---|
Selected | Overflow is possible for data in your chart and you want explicit saturation protection in the generated code. | Overflows saturate to either the minimum or maximum value that the data type can represent. | An overflow associated with a signed 8-bit integer saturates to –128 or +127 in the generated code. |
Cleared | You want to optimize efficiency of the generated code. | The handling of overflows depends on the C compiler that you use for generating code. | The number 130 does not fit in a signed 8-bit integer and wraps to –126 in the generated code. |
Arithmetic operations for which you can enable saturation protection are:
Unary minus: –a
Binary operations: a + b, a – b, a * b, a / b, a ^ b
Assignment operations: a += b, a –=b, a *= b, a /= b
Keep the following considerations in mind when you select Saturate on integer overflow:
Saturation applies to all intermediate operations, not just the output or final result.
The code generator can detect cases when overflow is not possible. In these cases, the generated code does not include saturation protection.
Charts use ANSI^{®} C rules for integer promotion.
All arithmetic operations use a data type that has the same word length as the target word size. Therefore, the intermediate data type in a chained arithmetic operation can be different from the data type of the operands or the final result.
For operands with integer types smaller than the target word size, promotion to a larger type of the same word length as the target size occurs. This implicit cast occurs before any arithmetic operations take place.
For example, when the target word size is 32 bits, an implicit cast to int32 occurs for operands with a type of uint8, uint16, int8, or int16 before any arithmetic operations occur.
Suppose that you have the following expression, where y, u1, u2, and u3 are of uint8 type:
y = (u1 + u2) - u3;
Based on integer promotion rules, that expression is equivalent to the following statements:
uint8_T u1, u2, u3, y; int32_T tmp, result; tmp = (int32_T) u1 + (int32_T) u2; result = tmp - (int32_T) u3; y = (uint8_T) result;
For each calculation, the following data types and saturation limits apply.
Calculation | Data Type | Saturation Limits |
---|---|---|
tmp | int32 | (MIN_INT32, MAX_INT32) |
result | int32 | (MIN_INT32, MAX_INT32) |
y | uint8 | (MIN_UINT8, MAX_UINT8) |
Suppose that u1, u2, and u3 are equal to 200. Because the saturation limits depend on the intermediate data types and not the operand types, you get the following values:
tmp is 400.
result is 200.
y is 200.
Suppose that you select Detect wrap on overflow (with debugging) in the Simulation Target pane of the Model Configuration Parameters dialog box. When you select Saturate on integer overflow, Stateflow^{®} does not flag cases of integer overflow during simulation. However, Stateflow continues to flag the following situations:
Out-of-range data violations based on minimum and maximum range checks
Division-by-zero operations