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.
C has one shortcoming that keeps bothering me. When converting a number from binary to decimal, we typically do something like : int n,d; for (i=0; i<5; ++i) {
d=n%10;
n/=10;
display_area[4-i]=d; } When doing firmware, we are always concerned about code space, and sometimes speed too. In either case, doing the division twice is a big waste of time and space. Some compilers will allow something like : int32 l; int16 n; int8 c; for (i=0; i<5; ++i) {
l/=10;
d=_REM4_; // where _REM4_ is the last remainder of a 32 bit division or
d=_REM2_; // where _REM2_ is the last remainder of a 16 bit division or
c/=10;
d=_REM1_; // where _REM1_ is the last remainder of a 8 bit division display_area[4-i]=d; }
On the Keil compiler, the most efficient way I found to do it is to use assembly, while knowing the name that the variable where I want to put the remainder will have after the compile step. This is far from being user friendly. Also, I haven't found a way to get the .lst file to list the compile code together with the source code when using the assembly code directive. Well, that creates a big mess just to save a few bytes...
Is there a better way ?
The subject has come up a couple of times. Unfortunately, there's no way I know of to access the results of a division later.
Properly (in my opinion), this is the province of the code generator and optimizer. It's reasonably common for code to need both the result and remainder of a division. The compiler should be on the lookout for a later use of the "other half" of a division or mod operation. Failing that, Keil could at least provide an intrinsic function similar to what you suggest, or one that provides both results.
The Keil linker does a lot of optimizations. The file that contains all of the assembly code, after all optimizations and linking, is the "code" (.cod) file produced by the linker. The .lst files are produced by the compiler, and so are the pre-linker-optimization results of translated the C source.