In our application we are using the latest fs_div28.asm file (from compiler tools v20.2.1 LTS, which seems to be the same as the one from v22.6.0 LTS) as is to perform floating point divisions, when testing for exponent overflows and divisions by 0 we found the following issues:
- When numbers that will cause an overflow are used the software is giving wrong results, for example:
F1 = 1.75e+34 (0x7858b717), large positive number
F2 = -1.96e-07 (0xb452f117), small negative number
F1/F2 = 2.35e-38 (0x01000008), small positive number
Checking the fs_div28.asm file seems like the intention of the code in the case of an exponent overflow is to return the max. valid positive and negative floating-point numbers (0x7F7FFFFF or 0xFF7FFFFF) but it’s not able to.
Looks like the underlying issue is the following: the code checks for overflows by loading the resulting floating-point exponent in the AL register, subtracting 255 and checking that the result is greater or equal to 0. Then the “OVERFLOW” handling section attempts to use the SAT instruction to fill the ACC register with 0x7FFF FFFF but, since the ACC register itself didn’t overflow the OVC doesn’t increase (remains as 0) and ACC is left the same so the final result in ACC isn’t correct.
Also, in case the resulting floating-point number is negative, ACC is saved into the P register, AH is modified but ACC is never restored before branching to the “Return Value” section.
2. When calculating divisions by 0 the results are either +3.38e+38 (0x7f7f0000) or –3.38e+38 (0xFF7F0000) depending on the sign of the dividend.
So, regarding issue 1, could anyone confirm if this is a problem in the fs_div28.asm or does the device need additional setup before being able to perform floating point decisions.
Regarding issue 2, is there any reason why these numbers are being used and not +/- infinity or the max. valid positive and negative floating-point numbers (0x7F7FFFFF or 0xFF7FFFFF)?
