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