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.

FastRTS 1.42 math issue !

Hello,

I integrated FastRTS 1.42 into our DSP firmware build and uncovered the following behavior/bug with respect to the standard RTS library provided with the BIOS we used.

Stats are as follows:

  • DSP BIOS v5.41.6.21
  • CGT 6.1.20
  • CCS v4.2.3.00004
  • HW: DaVinci 6446 device

Issue/bug is as follows with the code snippet below:

  • The following test will return FALSE with FastRTS linked in but return the correct TRUE answer with standard RTS:
  • atof(&wb[0]) >= 4.0 where wb is a character string, i.e. "4.0"
  • Note that the simpler 4.0 >= 4.0 also exhibits this wrong behavior with FastRTS vs RTS.

Please advise, this bug generates slightly different behavior/results in our floating point code.

Regards,

Serge

  • I came across a similar issue.  Here's an example:

    float64 a = 1000;
    float64 b = -1000;
    float64 c = 10;
    int32 d = (int32) ((a - b)/c);

    With the Fast RTS library, d = 199.  This problem goes away with the standard RTS library or by switching to float32.

    I am using version 1.42 of the FastRTL library with a c6424.

    Dan

  • Daniel,

    I have been able to replicate the issue, you have reported. This is indeed a bug in the divdp function in the fastRTS functions, I have reported the bug in the bug tracking.

    I also noticed that this issue doesn`t exist when the 64 bit double variables are defined as 32 bit float variables which means the issue doesn`t exist in divsp but does surface in divdp function. Can you work with float variables as a temporary work arround.

    Regards,

    Rahul

  • Thanks for looking into it.  I can use 32 bit floats as a work around.

    Dan