We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I need a 100% accurate division of any tow 32 bit numbers. So I am using the following code and the (/) operator. However I notice that results are not accurate when the Den (denominator) is shorter that 32 bit. For example (98765432/01234567) gives 120 where as the correct answer is 80. Can anyone tell me why ? Is something in my code incorrect More important, if this is not a bug, how to fix it ?
Incidentally, I cannot use Printf function so I am using a union function to map the long int variables into 4 unsigned char and the Display the char via a serial port. I don't think that process has introduced any errors in the calculations.
Thanks.
Bhal Tulpule
unsigned long int xdata Num,Den,Res; Num = 98765432; Den = 1234567; Res = Num/Den; //Display Res;
Can you use itoa() or something equivalent?
How about using the L or U suffix on the constants?
Prefixing something with zero also implies octal!
c0x.coding-guidelines.com/6.4.4.1.html
why not?
Probably because it's got a large footprint, and he only paid for the eval version? Or hasn't figured out a way to semi-host it?
Then again converting numbers back and forth between bases is pretty pedestrian stuff.
Folks, 1. I am trying to AUTOMATICALLY, i.e. programmatically, compare and verify the results of a division of ANY two long int numbers (not constants) with a HARDWARE device that I have designed and that does the same thing 1000 times faster. So I cannot use Printf function. 2. itoa is not a ANSI C function and it does not come with my (evaluation) C51 toolset. 3. My toolset does not recognize these (l or L) prefixes. Besides it is irrelevant to what I am trying to do.
So is there is standard piece of C code that can compute with 100 % accuracy, the division of two long int (i.e. 2 byte long) numbers ?
All helpful replies will be appreciated.
Thanks. Dr. Bhal Tulpule
You have designed a 1000 times faster hardware?
But you think decimal 98765432 and octal 01234567 are two good numbers to store in two bytes? The rest of the world have only managed to fit 65535 if using unsigned or 32767 if using signed.
itoa()? It's trivial to write an itoa() function. A decent coder can write one on a napkin while discussing the food.
Not sure why you're using an 8051 then, I've got a PC that runs multiplication and division about 3000x faster (or at least has a throughput there abouts) than the aforementioned Intel part.
I don't see enough code, or have enough familiarity with the 8051 C Compiler to know why valid C wouldn't serve up valid answers.
WSP BEng (Hons)
Obviously, that was a typo error, I meant 4 bytes as indicated by long int (just outside the bracket) in that line.
So your "rest of the world ..." comment was uncalled for.
The purpose of my effort is not converting characters to integers etc. but find an C code based method that can compute the ratio of two, 4 BYTE WIDE integers accurately, so that it can be automated and compared with the hardware version.
Perhaps, someone else, more helpful will try to answer the question that I asked.
Num = 98765432; converts to 2680 Num = 98765432L; is 98765432
converts to 2680
Not on any half-decent C compiler it doesn't.
As I see it, the Keil toolset is targeted for Embedded Applications. So a microprocessor such as 8051, or ARM processor would be a natural choice, as opposed to a PC however fast it might be. The code to compute an integer divide is trivial and so the question remains as to why valid C wouldn't serve up valid answers. Sometimes the answers are correct but for others they are wrong.
That's all fantastic, but you'd think you could provide some specific and complete test cases, as part of some experimental method? Providing information about the compiler version, and optimization settings. Enumerate the failing numbers so patterns might be apparent.
The 8051 compiler likely makes far more compromises, and optimization choices you might want to focus on. Appropriate casting on an 8-bit microprocessor, where default int size is 16-bit, being particularly important.