SPRUJG0C December   2024  – October 2026 F29H850DM , F29H850TU , F29H859TU-Q1 , F29P329SM-Q1 , F29P589DM-Q1 , F29P589DU-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
  5. 2Performance Optimization
    1. 2.1 Compiler Settings
      1. 2.1.1 Enabling Debug and Source Inter-Listing
      2. 2.1.2 Optimization Control
      3. 2.1.3 Floating-Point Math
      4. 2.1.4 Fixed-Point Division
      5. 2.1.5 Single vs Double-Precision Floating Point
      6. 2.1.6 Link-Time Optimization (LTO)
    2. 2.2 Memory Settings
      1. 2.2.1 Executing Code From RAM
      2. 2.2.2 Executing Code From Flash
      3. 2.2.3 Data Placement
    3. 2.3 Code Construction and Configuration
      1. 2.3.1 Inlining
      2. 2.3.2 Intrinsics
      3. 2.3.3 Volatile Variables
      4. 2.3.4 Function Arguments
      5. 2.3.5 Enabling Wider Data Accesses
      6. 2.3.6 Auto-Generated Code
      7. 2.3.7 Accurately Profiling Code
    4. 2.4 Application Code Optimization
      1. 2.4.1 Optimized SDK Libraries
      2. 2.4.2 Optimizing Code-Size With Libraries
      3. 2.4.3 C29 Special Instructions
      4. 2.4.4 C29 Parallelism
      5. 2.4.5 32-Bit Variables and Writes Preferred
      6. 2.4.6 Coding Style and Impact on Performance
  6. 3References
  7. 4Revision History

2.3.6 Auto-Generated Code

Performance needs to be optimized with code generation tools like Mathworks Embedded Coder which has specific suggested toolchain options.

Depending on the configuration settings, auto-generated code can have double-precision floating point operations and these can lead to significant deterioration of performance when running on floating-point hardware that supports only single-precision floating point operations.

It is also advised that users look for the following in the generated code:

  • Use of double-precision floating point types (double) or typedefs (for example, real_T).
  • Use of double-precision floating point constants. These are floating point numbers without a trailing f. Sometimes these have specific names, such as DBL_EPSILON. They are usually located in a _private.h file.
  • Ocurrences of double-precision operations in compiler generated assembly. These operations are implemented in software when FPU64 is not available or enabled. For example:
    • "CALLD @__extendsfdf2" (type extension from single-precision to double-precision)
    • "CALLD @__truncdfsf2" (type conversion from double-precision to single-precision)
    • "CALLD @__floatdisf" (type conversion from 64-bit integer to single-precision float)
    • "CALLD @__muldf3" (double-precision multiply)
    • "CALLD @__divdf3" (double-precision divide)
  • Leverage suggestions provided in Single vs Double-Precision Floating Point.

Auto-generated code typically has calls to several RTS library functions. As indicated in the Intrinsics section, the compiler generates optimized instructions for many of these functions. For expf() and its related functions, intrinsics must be leveraged.

Auto-generated code typically also contains functions that serve as building blocks or helper functions and are called several times by the software application. It is useful to analyze these functions as optimizations that result in better performance might exist (for example, rt_roundd(), rt_modf(), rt_delta_theta()).