• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 85 subscribers
  • Views 729 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: CLA compiler

Jacob Urcuyo15
Prodigy 20 points

Other Parts Discussed in Thread: C2000WARE

Tool/software: TI C/C++ Compiler

I have a question about the assembly that the CLA compiler is generating.

In the CLAmath.h file resides some inline functions.  If you take a look at the CLAasin_inline() function, for example, you will notice a variable declared xTblIdx.  If this variable is declared as 16-bits, the compiler generates some assembly that has branches in it.  Like at line 419 of cla_asin.asm.  What are these branches checking?

If the variable is declared as a 32-bit variable, the branches disappear and the performance improves, but I don't understand where the branches come from. I understand that when it is declared as 16-bits the compiler will have to convert to 32-bit, convert to float, floating-point multiply, then convert back to fixed-point.  But what do the branches have to do with this process?

Thanks,

Jacob

  • 0
    TI__Guru* 93800 points
    Hi Jacob - Can you post a screenshot of the code and disassembly you see?
  • 0 in reply to Lori Heustess
    TI__Prodigy 20 points

    Here's some screenshots of the files I mentioned.

  • 0 in reply to Jacob Urcuyo15
    TI__Guru**** 253170 points

    My guess is the C source and disassembly don't associate the way it appears.  For the source file which produces the problem assembly code, please submit a test case as described in How to Submit a Compiler Test Case.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 253170 points

    Please submit the requested test case.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Mastermind 32995 points
    George,

    This is the asin example in the CLA math library.

    C:\ti\c2000\C2000Ware_1_00_05_00\libraries\math\CLAmath\c28\examples\asin

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    TI__Guru**** 253170 points

    I am unable to reproduce the problem.

    I import the project at this location ...

    Sal Pezzino said:
    C:\ti\c2000\C2000Ware_1_00_05_00\libraries\math\CLAmath\c28\examples\asin

    ... into CCS.  It contains one source file with the extension .cla.  I add the option --src_interlist.  This option causes the compiler generated assembly file to be kept (it is normally deleted), and interlisted with comments that make it easy to associate the assembly code with the C code.  After building, I inspect the assembly code.  It contains only one MBCNDD instruction.  And that instruction is clearly related to an if statement.

    So, there must be more to it.  The quickest way for me to reproduce the problem is for you to submit a test case as described in the article How to Submit a Compiler Test Case.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Mastermind 32995 points

    The problem doesn't exist in what was released, because we used uint32_t or int32_t for xTblIdx in what is released to increase the performance. If it is changed to uint16_t or int16_t, then the weird branches appear again. The source for the inline C function is in CLAmath.h

    Please change the xTbblIdx to int16_t.

    sal

    CLA_16v32.zip

  • 0 in reply to Sal Pezzino
    TI__Guru**** 253170 points

    Sal Pezzino said:
    If it is changed to uint16_t or int16_t, then the weird branches appear again.

    That was explained in the first post.  I'm sorry I overlooked it.

    I can give a partial explanation.

    The expression u32 * 3 is changed to (u32 * 2) + u32, then changed again to (u32 << 1) + u32.  Assembly code is generated for that expression.  I don't know why this optimization is only applied to 32-bit expressions, and not 16-bit ones.

    Suppose the expression were instead u32_v1 * u32_v2.  No constants.  This expression is implemented with a sequence of assembly instructions that involves shift, add, and a loop.  Because the expression u16 * 3 is not optimized, a similar sequence is generated for it.

    That's as much as I understand.  If you need more detail, then I need to involve the compiler development team.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Mastermind 32995 points
    Hi George,

    I think I understand. The issue still remains if the compiler optimization levels are bumped up.

    I think this would be something that should be added for optimizing 16-bit integers math operations. I would like to still bring it to Cody's or Greg's attention to implement in some future release.

    Thanks,
    sal