Divide by zero, what happens?

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...

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.

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!

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.