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/TMS320F28335: 32bit division: "/" or instrinsic?

Part Number: TMS320F28335
Other Parts Discussed in Thread: C2000WARE

Tool/software: TI C/C++ Compiler

Hi all,

I'm quite new in the world of TMS320 DSCs and I'm programming a TMS320F28335 in C language, using the compiler with "-o3" optimization level. I need to compute 32-bit divisions, both in floating and fixed point (let's say float/float and int32/int32). I was looking in TI documenation for a good method to perform these computations but I got a little confused. I don't know if it's better to simply write

var_a = var_b / var_c;

and trust in the compiler, or to use instrinsics; for example I found EINVF32 for floating point inverse, followed by 2-step Newton-Raphson.

What is the best solution in your opinion?

Many thanks!

Best regards,

Alessio

  • Alessio,

    I believe the behavior is dependent both on the code you write as well as the inclusion of TI provided math libraries.

    For example, if you didn't include any TI provided math libraries other than the standard 2800_RTS run time support library, then the "/" would simply map to however the RTS library implements division (floating point or fixed).

    On the other hand, if you included the FPUFastRTS math library, then the "/" would map to FS$$DIV (see C:\ti\c2000\C2000Ware_1_00_06_00\libraries\math\FPUfastRTS\c28\docs). This library speeds up the routines at the expense of accuracy. For Fixed point, if you included the IQMath library, then you could use _IQdiv or _IQNdiv to implement division (see C:\ti\c2000\C2000Ware_1_00_06_00\libraries\math\IQmath\c28\docs).

    Another alternative is to use intrinsics, where you would have to look at the description of the intrinsic to understand what its functionality and features are. There are division intrinsics available on the C28x, the FPU (if the device contains one), and the TMU (if the device contains one).

    Bottomline is, there are many options available to you, you have to pick the one that fits your need.

    Thanks,
    Sira
  • Dear Sira,

    many thanks for your reply, that explained options that I didn't consider. I gave a look to documents you said and to ASM sources: I found many useful information. Now, I'd like to try those divison functions but only in a little portion of my code. Can I directly call FPU_FastRTS functions (for example) without using the whole Run-time Support library? I mean, I would avoid the compiler to replace all divisions in my code with that algorithm.

    Thanks for your help.

    Best regards,

    Alessio

  • Alessio,

    Are you saying you would like to use FPUFastRTS functions in certain places in your code, and normal RTS functions in other places?

    If yes, that is an interesting question. Because my understanding is that in order to use FPUFastRTS functions, you have to include the FPUFastRTS library, and in CCS project linker options, you have to instruct CCS to go look for the functions first in the FPUFastRTS library, before looking in the standard RTS library (these instructions are in the user guide - you may have seen them already). There are only a limited number of FPUFastRTS functions (division being one of them), but yes, its inclusion would essentially imply its use in all occurences in the project.

    Let me know if I understood your question correctly, and I'll dig into this possibility a bit more (my initial thought is I'm not sure there is a clean way of accomplishing it).

    Thanks,
    Sira
  • Sira,
    you understood the question perfectly. My idea is to call FPUFastRTS functions only in certain places of my code, without replacing the normal RTS functions.
    Many thanks for your help!
    Alessio
  • Alessio,

    I think you would have to include the FPUFastRTS library as LOWER priority than the standard RTS library (in CCS project settings), and furthermore, wherever you want standard division you can use the / symbol, and wherever you want the FPUFastRTS division, you could use the FS$$DIV (just not sure how you would pass Numerator and Denominator arguments and receive the Quotient/Remainder).

    For the other operations of the FPUFastRTS library (other than division), I think the above approach will work and the call methodology is also clear. Perhaps you can give it a shot e.g. for the sin or cos?

    On this last point, I am checking and will get back to you tomorrow.

    Thanks,
    Sira
  • Alessio,

    My apologies - for the standard math library functions like sin, cos, atan, atan2, and sqrt, if you include the FPUFastRTS library with LOWER priority than the standard RTS library, then the linker will always use the Standard RTS library implementation of the function. There's no way around it.

    For functions like isqrt and sincos, these are unique to the FPUFastRTS library, so the library priority doesn't matter. The linker will only find these functions in the FPUFastRTS library.

    So now the only question that remains is with the division, whether FS$$DIV is something that can be used instead of / to invoke the FPUFastRTS library division function. I'll get back to you on this.

    Thanks,
    Sira
  • Dear Sira, many thanks for your help. I'm looking forward to your reply.

    Best regards,

    Alessio

  • Alessio,

    I don’t think this could be possible with the current implementation, because FS$$DIV is actually not a C callable function i.e. it does not accept any arguments rather it’s just a symbol. The assembly routine already assumes that numerator and denominator are passed through R0H and R1H registers, so one way is to modify this assembly routine by making this as a C callable function and adding instructions to assign arguments to R1H and R0H and building the library again. This seems to be the only way to do it.

    Thanks,
    Sira
  • Sira,

    many thanks for your help. I will try with this approach.

    Best regards,
    Alessio