Why is the generated code different for the same model using Real-Time Workshop 5.0 (R13) and Real-Time Workshop 6.2 (R14SP2)?

I am using the FCN block with a relational expression such as:

 u[5]>u[4] + u[5]<u[3] + u[2] + u[2] <u[3] > u[4]

The code generated by Real Time Workshop 6.2 (R14SP2) for this block is different from the code generated by Real Time Workshop 5.0 (R13). The code for R13 is as follows:

 /* Fcn: '<Root>/Fcn' incorporates: 

    *   Constant: '<Root>/Constant' 

    * 

    * Regarding '<Root>/Fcn': 

    * Expression: u[5]>u[4] + u[5]<u[3] + u[2] + u[2] <u[3] > u[4] 

    */ 

   rtb_Fcn = rtP.Constant_Value[4] > rtP.Constant_Value[3] + 

     rtP.Constant_Value[4] < rtP.Constant_Value[2] + 

     rtP.Constant_Value[1] + rtP.Constant_Value[1] < 

     rtP.Constant_Value[2] > rtP.Constant_Value[3];

The code for R14SP2 is as follows:

 /* Fcn: '<Root>/Fcn' incorporates: 

    *  Constant: '<Root>/Constant' 

    */ 

 rtb_Fcn = (real_T)((real_T)((real_T)((real_T) 

 (fcn_block_P.Constant_Value[4] > fcn_block_P.Constant_Value[3] + fcn_block_P.Constant_Value[4]) 

 < (fcn_block_P.Constant_Value[2] + fcn_block_P.Constant_Value[1]) + fcn_block_P.Constant_Value[1]) 

 < fcn_block_P.Constant_Value[2]) 

 > fcn_block_P.Constant_Value[3]);

The result seems to be the same, but the code generated is different.

Answer 1

[MathWorks Support Team]

In Real-Time Workshop 6.2 (R14SP2), we added an optimization stage to transform expressions that are right-recursive into expressions that are left-recursive. If you draw an abstract syntax tree for the expressions, the original tree is heavier on the right, while the transformed tree is heavier on the left. The transformation works as follows: for any commutative binary operator, we look at the depth of the expression tree below each operand, and emit the operand with the greatest depth beneath it first.

The transformed expression is numerically identical and will lead to a more efficient implementation (less ROM/RAM) on some compilers. In one experiment, we found a factor of 2 reduction in ROM when using the optimization. For a compiler with limits on stack depth, the optimization can make the difference between successful and unsuccessful compilation. Note: The optimization can affect code traceability.

There are no workarounds in R14SP2 to generate code similar to R13.