This is a confirmed bug. Keil says "This is so rare, don't expect it to be fixed anytime soon". In grade school you were taught 0 / anything is 0. 0 / 0 is 0. According to Intel, this is undefined for the 8 bit divide instruction. The Keil simulator returns a 0 if you do an 8 bit division using the 8051 divide instruction. Silabs returns a 0xFF and the Keil compiler makes no error checks. Thus the following code returns the wrong answer under the Keil compiler unsigned char result; unsigned char variable1; unsigned char variable2; variable2=0; result = variable1/variable2; This will yield result = 0 on the simulator, but result = 0xFF on the silabs CPU. I don't know what other cpu's do, but suspect they do the sane thing of returning 0. This caused me a lot of grief when variable2 was the value read from a timer register. sometimes the code would work, sometimes it would fail. Unfortunatly when it failed, the user of the instrument that I was writing the code for would get a 300 VOLT shock. Keil verified the result, but refused to fix the unsigned divide function (whic is optimized) to check for the incoming values both being less than 0xFF and uses the hardware 8/8 divid instruction. Of course, it does not return an error per se, but then the library function does not check for error and return 0 either like it SHOULD. Needless to say I'm ticked that a 1600+ dollar program has something like this, and even more ticked that Keil has refused to make the source for the divide routines available, or fix this one. I have at this time, programmed around the problem so the code works, but there is just plain no excuse for this sort of thing. Apparently they validate thier functions with thier simulator. The fix would be very easy. After doing the divide, check for the error condition and clear acc if it is set. Cheers Woody Baker
The fix would be very easy. After doing the divide, check for the error condition and clear acc if it is set. This is baloney. The value returned by divide by 0 is undefined (since infinity is not a binary value), whether a divide by zero happened can be seen by testing the flag returned. (see "the bible" chapter 2). The result of divide by zero is NOT 0 but infinity. Erik
The ANSI C standard in section 6.5.5 has this to say about division by zero: "5 The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behavior is undefined. 6 When integers are divided, the result of the / operator is the algebraic quotient with any fractional part discarded.87) If the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a." There is no real way to perform a division by 0 since the results are either indeterminate (0/0) or undefined (x/0). Furthermore, adding a check into the division routine slows ALL division routines for ALL customers. This is unnecessary and unwaranted. If we added this non-ANSI feature, we would then have customer complaining about how slow our division routines are. More interesting detail about division by 0 may be found at the following URL: http://mathforum.org/dr.math/faq/faq.divideby0.html Jon
In grade school you were taught 0 / anything is 0. 0 / 0 is 0 In grade school I was taught that division by zero was undefined and to be avoided. This point was particularly important in algebra, where if a division by zero, symbolically disguised of course, sneaks into your manipulations, you likely get the wrong answer. The lack of definition is easy to work around. You check for zero before doing the division. If you want the result in such a case to be zero, then so be it.
result = 0; if (divisor != 0) result = dividend / divisor;
In grade school you were taught 0 / anything is 0. 0 / 0 is 0. No, I wasn't. And I would be rather furious at my teachers in retrospect if I had been. Anything divided by zero is undefined, period. Thus the following code returns the wrong answer under the Keil compiler That cannot possibly be the case. For division by zero, every given answer is just as correct as any other one --- and just as incorrect, too. The bug is strictly in your code, not in how Keil compiles it. And your attitude expressed here makes me seriously doubt whether you should ever have been allowed to write code that administers voltages as potentially high as 300V to people.