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/TMS570LS0432: Division and ABI helper-functions from runtime library

Part Number: TMS570LS0432


Tool/software: TI C/C++ Compiler

Hi TI team,

I had to look a bit deeper to the division implementation within the ARM 18.12.0 compiler and the corresponding runtime library and found the following behavior:

- 16-bit division is done by embedded call of SDIV

- 16-bit modulo division is done by helper-function __aeabi_idivmod

- 32-bit division is done by embedded call of UDIV / SDIV

- 32-bit modulo division is done by helper-functions __aeabi_uidivmod / __aeabi_idivmod

- 64-bit division is done by by helper-functions __aeabi_uldivmod / __aeabi_ldivmod

- 64-bit modulo division is done by helper-functions __aeabi_uldivmod / __aeabi_ldivmod

I found it not very consistent for case when dividend and/or divisor is equal to 0.

UDIV/SDIV returns 0 in this case, while helper function could return MIN/MAX data types.

Is there any possibility to use helper function in all the cases? instead of using embedder UDIV/SDIV.

Thanks in advance,

Dmitry

  • There is no method by which you can force the compiler to implement a division expression a particular way.  The compiler will use either an instruction like SDIV or call a function from the RTS like __aeabi_idivmod.  

    For the case where a function like __aeabi_idivmod is used, you can control what happens when divide by 0 is detected.  The TI ARM compiler, like nearly all ARM compilers, adheres to the standard ABI for the ARM architecture.  This specification requires that, when divide by 0 is detected, the function __aeabi_idiv0 (for 32-bit divide) or __aeabi_ldiv0 (for 64-bit divide) gets called.  For further details, please search this page from ARM for the term Division by zero.  

    For example, you could add these two C functions to your system ...

    int __aeabi_idiv0(int return_value)
    {
       return 0;
    }
    
    long long __aeabi_ldiv0(long long return_value)
    {
       return 0;
    }

    These example functions are written to always return 0, which matches the behavior of the instructions SDIV and UDIV.  

    Thanks and regards,

    -George

  • Hi George,

    thank you for your answer.

    Yep, it is understandable that __aeabi_idiv0 and __aeabi_ldiv0 could be redefined, thus quotient could be redefined as well. The whole helper could be reworked for 64-bit division and 32-bit modulo division, so not an issue.

    But since it is not possible to force calling __aeabi_uidivmod and __aeabi_idivmod, division by zero cannot be redefined for 32 bit division. And it is a bit pity cause in accordance with the referenced by you document:

     

    Ideally, a *divmod function should return {infinity, 0} or {0, numerator}, where infinity is an approximation.

    And it is not possible to get this infinity for 32-bit division.

    Nevertheless thank you for your answer. I just thought that maybe some compiler flag is available to force using helper functions for 32-bit division.

    Regards,

    Dmitry

    P.S. If you don't mind, just another short question. Does TI provide some documentation with description of the runtime library and its functions behavior?

  • Dmitry Tuykov said:
    Does TI provide some documentation with description of the runtime library and its functions behavior?

    Yes, but it is limited.  Search the TI ARM compiler manual for the chapter titled Using Run-Time-Support Functions and Building Libraries.  The divide routines discussed in this thread are not documented in that manual.  The complete source code for the RTS library is part of the compiler installation.  If you have Code Composer Studio installed, it is located in a directory with a path similar to ...

    C:\ti\ccs1000\ccs\tools\compiler\ti-cgt-arm_20.2.0.LTS\lib\src

    Thanks and regards,

    -George

  • Hi George,

    thank you for your answer. Thread could be closed.