TMS320F28388D: Natural logarithm function from fastRTS is not giving the correct value.

Gurusha,

The image did not come through.  Could you try posting again.  There are instructions for inserting images here that can help: 

Regards,

John

John,

It didn't fully upload because of some network issue, I guess!

Gurusha,

I see you are including math.h but also you have a prototype for logf() at the top of your source file.  Why is that?  Including math.h should have been sufficient.

What happens if you step into line 29 using the debugger?  Does it go to the source for logf() that you are expecting?

Regards,

John

John,

I have removed and tested again but it doesn't make any difference.

Yes I checked in disassembly, it is going inside the logf() function and performing the operation. But only issue is I am not getting correct value for negative number. is it so, that we need to give input always greater than 1? even if we give negative number as an input, the absolute operator will do the job right?

Could you please check this from your end?

Thanks

-Gurusha

This is beyond my expertise.  I will see of someone else can jump in, otherwise you will need to wait until George returns next week.

I don't have a F28388D devices but on my F280049C and F28069 this is what I see.

When I step into logf() it steps into e_logf.c. I am using the standard RTS library that ships with the compiler.

Regards,

John

gurusha nahar said:

When I was testing a negative number, for which log function should convert it into its absolute value and give the result. I am afraid I am not getting the correct value.

I don't have a TMS320F28388D, but have repeated your results on a TMS320F28379D which calls the logf() from C2000Ware_3_03_00_00_Software/libraries/math/FPUfastRTS/c28/lib/rts2800_fpu32_fast_supplement_eabi.lib :

The logf() call with a positive input returns the expected value; it is the call with the negative value which causes the incorrect value.

Note that the standard library logf() is specified to return a NaN for a negative input.

Whereas the algorithm for "Fast single precision natural logarithm for the C28x + FPU32" in the FPUfastRTS log_f32.asm is commented as starting by taking the absolute value of its input.

The project is attached. TMS320F28379D_logf.zip

C2000Ware_3_03_00_00_Software/libraries/math/FPUfastRTS/c28/source/fpu32/log_f32.asm has:

    MOV         ACC, LF_ABS_X_H << 9 ; AH = x.exp
    SUB         AH, #127             ;    = x.exp - SP_BIAS

    ;; ANDing the argument with 0x3FFFFFFF will zero out the sign bit, which 
    ;; is equivalent to doing the absolute operation, and the most significant 
    ;; exponent bit while ORing with 0x3F800000 will set the exponent to 
    ;; 127 (single) or 1023 (double)
    ;;
    ;; Consider 10 = 1.25x2^3. In single precision float the leading 1 of the 
    ;; significand is implicit and the exponent is biased around 127, so its 
    ;; physical representation is 
    ;;   31|30           23|22                                        0|
    ;;   +-+---------------+-------------------------------------------+
    ;;   |0|1|0|0|0|0|0|1|0|0|1|0                 ...........         0|
    ;;   +-+---------------+-------------------------------------------+
    ;;    S| biased exp    | mantissa                                  |
    ;;     | E = 127+3=131 | 0.25                                      |
    ;;
    ;; X & 0x3FFFFFFF
    ;;   31|30           23|22                                        0|
    ;;   +-+---------------+-------------------------------------------+
    ;;   |0|0|0|0|0|0|0|1|0|0|1|0                 ...........         0|
    ;;   +-+---------------+-------------------------------------------+
    ;;    S| biased exp    | mantissa                                  |
    ;;     | E = 2         | 0.25                                      |
    ;; (X & 0x3FFFFFFF) | 0x3F800000
    ;;   31|30           23|22                                        0|
    ;;   +-+---------------+-------------------------------------------+
    ;;   |0|0|1|1|1|1|1|1|1|0|1|0                 ...........         0|
    ;;   +-+---------------+-------------------------------------------+
    ;;    S| biased exp    | mantissa                                  |
    ;;     | E = 127       | 0.25                                      |    
    ;; Now the value of this float (after removing exponent bias)
    ;;   = 1.25 * 2^(127-127(BIAS)) = 1.25
    ;; We have extracted just the mantissa (or significand)
    AND         LF_ABS_X_H, #0x3FFF  ; (x&0x3FFFFFFF)|0x3F800000
    OR          LF_ABS_X_H, #0x3F80  

I think the issue is that the AH register is set as the "x.exp - SP_BIAS" prior to the sign bit being zeroed. With a negative input this results in "x.exp - SP_BIAS" being set incorrectly, leading to the incorrect result.

I.e. does appear that the logf() from FPUfastRTS is not behaving as documented for negative input. I'm not a C2000 assembly expert, so not sure how the log_f32.asm file should be changed.

Gurusha,

Possibly there is a bug in the implementation for a negative input, I can file a JIRA for this.

Why are you even allowing negative values? The behavior for the standard RTS library function is to return an error. I am not sure why our library even accepts negative values. Can you not check the sign of the value prior to performing the operation?

Thanks,

Sira