OSDev.org

Hello!

I've got a simple question about a problem, where I've not idea why but guess that it could be a problem because of architecture.

Why is there a 'divide by zero exception'? Could this problem not been solved by software manipulation?

Can you help me please?

Thanks a lot

What do you mean with "software manipolation"? Dividing by 0 is a big math problem... The processor need to handle this error so there is an exception for this. Try to think what coul happen if your pc need to write the value to an industrial machine. Exceptions not handled could mean lives destroyed... And I'm not kidding

I think making it an exception, reduces your code so that you don't have to check a CPU flag every time the CPU issue the divide instruction. In some CPU architectures you might shut this exception off if you want or you can make the exception return doing nothing, it's up to you really. I think the exception there to help us rather there to annoy us. In a sense, if there is a divide by zero your program is faulty and it should be closed. Continuing could lead to unexpected results.

Hi,

skandalOS wrote:Why is there a 'divide by zero exception'?

There isn't!

There is a "divide exception" for overflow. For example, (for the DIV instruction) dividing the 64-bit number 0x123456789ABCDEF by the 32-bit number 1 causes a "divide exception" because the result is too large to fit in a 32-bit register.

Division by zero causes an overflow (and the overflow causes a "divide exception").


Cheers,

Brendan

Brendan wrote:Hi,

skandalOS wrote:Why is there a 'divide by zero exception'?

There isn't!

There is a "divide exception" for overflow. For example, (for the DIV instruction) dividing the 64-bit number 0x123456789ABCDEF by the 32-bit number 1 causes a "divide exception" because the result is too large to fit in a 32-bit register.

Division by zero causes an overflow (and the overflow causes a "divide exception").


Cheers,

Brendan

So what what happens if you divide 0x1234 with 0 then?

OSwhatever wrote:So what what happens if you divide 0x1234 with 0 then?

The processor repeatedly tries to subtract 0 times 2^bitnumber and then comes to the conclusion you can fit 0xffffffffffffffff times 0 in 0x1234. That's too big for a 32-bit number so a divide error is generated.

a) It's not completely true, a processor may implement this "function" in a different way.
b) I hope no processor uses the method you said. It's very slow between big numbers divided by small ones.

We can just say that there is this exception not how it works inside because intel could provide a different solution from other clones.

Karlosoft wrote:a) It's not completely true, a processor may implement this "function" in a different way.
b) I hope no processor uses the method you said. It's very slow between big numbers divided by small ones.

A typical hardware division performs bit_count sequnces of shift-compare-subtractconditional-rotatewithcarry just like you would do long division on paper (the difference is base 2 vs base 10). Integer division is in fact the slowest integer operation a processor supports because of the amount of dependencies between steps compared to multiplication which can just be rewritten as a large sum with the corresponding amount of electrical parallelism. In all cases, the dumb algorithm performs linearly to the number of bits in the operand (assuming the processor can do basic operations on those widths in a single clock which usually is the case).

In the end, all processors will perform some version of long division (where more performance means more transistors). A division by zero however has different effects in different implementations and may have to be special-cased to maintain the backwards compatibility with the "dumb" algorithm.

Does the CPU use numerical approximation like Newton-Raphson method? If an initial guess value is required it may be deduced by difference in position of MSB.

bluemoon wrote:Does the CPU use numerical approximation like Newton-Raphson method? If an initial guess value is required it may be deduced by difference in position of MSB.

I know Intel SSE does this with their fast division instructions. They have a list in the CPU for an initial accuracy that can later be refined with a few Newton-Raphson iterations.

OSwhatever wrote:

bluemoon wrote:Does the CPU use numerical approximation like Newton-Raphson method? If an initial guess value is required it may be deduced by difference in position of MSB.

I know Intel SSE does this with their fast division instructions. They have a list in the CPU for an initial accuracy that can later be refined with a few Newton-Raphson iterations.

Just like 3D graphical do not calculate COS and SIN calculations but look in a table of pre-calculated values.

bluemoon wrote:Does the CPU use numerical approximation like Newton-Raphson method? If an initial guess value is required it may be deduced by difference in position of MSB.

This was about integer divisions, which are specified to have perfect accuracy and therefore can't use iterative approximations by design. For floats it's a slightly different matter because it can not represent perfect accuracy. Even so, fdiv is accurate to the bits available (assuming it's bugfree for which there's a record). 3DNow added approximating reciprocals (of square roots), the concept of which later found it's way into SSE.

Did I misunderstood, or integer arithmetic is meant to be inaccurate and round off to the nearest decimal?

bluemoon wrote:Did I misunderstood, or integer arithmetic is meant to be inaccurate and round off to the nearest decimal?

Integer arithmetic doesn't get rounded off, hence the existence of the modulo-operator/remainder (which is stored in EDX, in case of the x86-architecture).


Yours faithfully
S.J.R. van Schaik.