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.

float division problems in C6711D

Hi , I have problems with float point division.

uss rts6700.lib V7.0.5 
FADCR default
FAUCR default
FMCR default
CFLAGS = -mv6710 -O2 -ms0  --quiet --diag_warning=225 --interrupt_threshold=1000 --opt_for_speed=5 -k --asm_listing --output_all_syms

formula is =INT((5+X)*10000.0/4000+0.5)

input formula result from C6711D
0 13 10
1 15 12
2 18 32
3 20 32
4 23 18
5 25 20
6 28 22
7 30 24
8 33 26
9 35 64
10 38 64
11 40 64
12 43 33

Any idea about it ?

  • More information

    in the formula INT((5+X)*10000.0/4000+0.5) , the value 4000 is a variable so it is a division in run time.

    And if  /4000 is rewritten as * _rcpsp((REAL32)4000.0), the result is the table

    input formula result from C6711D
    0 13 12
    1 15 15
    2 18 17
    3 20 20
    4 23 22
    5 25 25
    6 28 27
    7 30 30
    8 33 32
    9 35 35
    10 38 37
    11 40 40
    12 43 42

  • I'd assume that your differing results with _rcpsp() simply are caused by inaccuracies - it's a single-precision floating point operation, and so the amount of iterations to get the reciprocal is very restricted. See f.e. the explanation for _rcpsp() in spra516. For the algorithm in general see f.e. this.

    Concerning your first results I'd say that for some reason (at least if you actually wrote the test with constants) the compiler precalculated 10000.0/4000 rounded to integer 2. But that does not explain the result numbers 32 and 64 and 33 - which leaves me at a loss.

    Regards,
    Joern.

  • Thanks Joern.

    The result for -rcpsp() could be understood for limited accuracy. But actually what I have written in the code is not a constant 4000, but a variable. So there is no precalculation. What really trouble me is that I do not know how to produce a correct float division. Any proposal for it ?

  • At least for me (at C674 of DM8148) I can't get the strange behaviour from your first try above. I get exactly the awaited values (by res= int( ( 5 + x) * 10000.0 / val + 0.5); with int val= 4000; elsewhere before).

    So I all can provide are some thoughts:

    • Instead of  _rcpsp() you might use _rcpdp(), which deliveres double precision.
    • You might ensure that INT() in your code actually does what you mean.
    • To know about the actual build result you might analyze the “compiler feedback” - maybe that gives an idea. For that use the compile options '-k' (keep assembly files) and '-mw' (additional compiler feedback within the assembly files), which should produce commented assembly files. Option '-s'  should deliver source after high-level optimization.

    Also it might be helpful to provide the exact version of the tools you're using, maybe there is anywhere an issue yet in an older version.

  • Hi Joern:

    Sorry, it takes me a long time to get a CCSV5 license. I retest the same code in the V5, and the issue seems fixed.

    Although I do not know the root reason for this problem, I can use the ccsv5 to avoid the issue.

    input formula TI7.3.1 + rts6700.lib + CCSV5
    0 13 13
    1 15 15
    2 18 18
    3 20 20
    4 23 23
    5 25 25
    6 28 28
    7 30 30
    8 33 33
    9 35 35
    10 38 38
    11 40 40
    12 43 43

    I attach the v4 and v5 map file, hope it can help you to understand the issue more clearly.

    There is only one line calling divf, so you can easitly locate the in the asm file

    http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/115/3108.map_2600_asm.7z