• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 8695 views
  • Users 0 members are here
Support feedback
Options
Options

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.

Divide by zero, what happens?

H_Smith
Prodigy 220 points
Other Parts Discussed in Thread: TMS320F28335, TMS320LF2407A

I am working with both the TMS320LF2407A TMS320F28335 and have a basic question about division by zero.

I cannot seem to find any documentation about either Traps or C exceptions related to division by zero.

I would like to know how to detect and trap accidental divide by zero statements.

Are there special considerations for floating point divide by zero exceptions?

Thank you in advance.

  • 0
    TI__Expert 4745 points

    I believe the short version is that the math library that supports division defines "what happens."

    There are no "automotic" traps for Not a Number built into the architecture.

    http://focus.ti.com/docs/toolsw/folders/print/sprc664.html

    The above document provides some support for what happens when you use TI's FAST-RTS library.

    The short answer based on this document for the 2833x is:

    "Division by 0.0 sets the LVF flag."

    Hope this helps...

  • 0 in reply to DaveB123
    Prodigy 220 points

    Thank you for the information.

    Do you have any theories as to what happens when you are performing simple integer division in the C environment on these processors?

    I am guessing that the result is just indeterminate and that there are no traps or exceptions?

    The reason why I ask is that I am working with old legacy code and I have found several instances of division by zero and would like to understand what the consequences are if those statements are executed.

     

  • 0 in reply to H_Smith
    TI__Expert 4745 points

    It's hard to say without looking at the code.  You might want to see if you can locate a SIMULATOR plug in to Code Composer and run some

    numbers through this legacy code.

    In an the world of 16 bit integer math in embedded processors/DSP, typically divide by zero should result in a "saturation" of the 16bit value.

    This assumes the ALU control register is initialized to saturate on overflow. 

     In signed 2's complement that's 7FFFh or 8000h.  So, an OVERFLOW bit in the status register would be set.

    In order for your code to TRAP, you would have to have software check that OVFL bit to determine if the last calculation had exceeded the maximum representable

    number.

    If the "saturate on overflow" status is not established, then you have a really big issue because the 16 bit values can "wrap around" on themselves.

    Monitoring the CARRY bit can give you some help there as the transition from FFFFh to 0000h (wrap around) will set the Carry bit and I believe, vice-a-versa

    is also true (0000h - 0001h = FFFFh)  Note that in UNsigned math you wrap from the largest to the smallest representable number...that can be a huge

    issue if you are trying to control a system based on the numerical results of an algorithm.

    Hope this helps!

  • 0 in reply to DaveB123
    Prodigy 220 points

    Thank you for the detailed response.

    The legacy code I am working with is written in C. I have tried to properly check for divide by zero conditions in the legacy code but I did not know what would happen if a divide by zero occurs.

    Some of the legacy code that I need to support is written in C and runs on a LF2407A. There are many copies of the legacy code that have been distributed and I am concerned that divide by zero will occur on those systems (due to bugs in the C code).

    Since I am working in the C environment., and there are no traps or interrupts when a divide by zero occurs, my guess is that it would be more work to check the overflow flags, etc, than to just make sure this condition can never happen?

    Thanks.