One of THE worst things you can do in C51 code is to haphazardly use integers where unsigned chars (bytes) will suffice. Particularly when indexing arrays. While this may seem obvious to some, in my years of changing diapers (i.e. working on code written by other's who are now off destroying some other company's software department) I have run across this mistake countless times, where the non-obvious result is at least over-bloated code and/or, at worst randomly dysfunctional code. Does ANYONE in this industry bother taking the time to inspect the assembly code resulting from a compile? Does anyone even care? ...or is 95% of the industry filled with hacks who verify their code by functional "appearance" alone? My experience suggest the latter. The Moral: Keil C51 is without question top notch, but its not magic. Thus, do your career and your company a favor an make an effort to understand the 8051 indepth and understand what is and what isn't good C51 programming techniques. [end rant]
I found it well worth while when I started my project to examine the assembler listing, as well as re-write the same routine in different ways to observe the changes. Once I got a good feel for what the code generator was going to do in various circumstances, and what the limitations are, I could write C without having to worry about the output in most cases. I continue to go back and check routines when the change in size or speed seems contrary to my expectation, as well as checking important routines or common access patterns. I'd recommend anyone starting on an 8051 project do the same thing to educate themselves on how to make the architecture work for you. The 8051 is quirky, and the compiler adds some quirks of its own. Those quirks can make your life miserable if you don't keep them in mind.
I'd recommend anyone starting on an 8051 project do the same thing to educate themselves on how to make the architecture work for you. The 8051 is quirky, and the compiler adds some quirks of its own. Those quirks can make your life miserable if you don't keep them in mind. Absolutely. Take the time to experiment and learn what C language constructs bottleneck the resulting assembly code. Play with it and learn. In the end, it will save you time...granted, time that can't be tabulated on a quarterly report, so it will probably never be allocated, thus do it on your own time if you have to.
To be honest I find that checking the assembly is largely a waste of time at optimisation level 9 with linker code packing. One can spend time tweaking the 'C' to help the optimiser save a few bytes, then add or change a bit of code elsewhere in the project only to discover that this completely undoes any benefit derived from all that tweaking. Reversing the tweaks may then show a reduction in code size... Using the smallest integer size possible is such an obvious source level optimisation that I doubt anyone incapable of seeing this would be able to understand an assembly listing anyway.
To be honest I find that checking the assembly is largely a waste of time absolutely for an experienced Keil '51 programmer. However, if you are just starting out doing some peeks can yeld extremely valuable information about what the compiler "likes" and "dislikes". One example if you have a look at the difference between xdata treated as = pointer[index] index++ vs = *pointer pointer++ it will be educational. Erik
as = pointer[index] index++ vs = *pointer pointer++ Excellent example and is precisely what instigated my rant in the first place. Not only did the original hack (uh..author) index arrays like your top example, he used a signed integer to do it...and the array is only 64 elements long. To make matters worse, this was done numerous times within a repetative timer interrupt with an interval as low as 625uS. Comparing the execution time of the resulting assembly to this interval yeiled an overrun by anywhere from 8 to 108 machine cycles. Yet, somehow this code made it through review and QA...which only serves to reconfirm my belief that software QA is little more than a "feel good" regulatory appeasment.
"Not only did the original hack (uh..author) index arrays like your top example..." Oh no, not that old chestnut again: It is not a foregone conclusion that pointers are inherently better than array indexing! See: http://www.keil.com/forum/docs/thread1156.asp "...he used a signed integer to do it...and the array is only 64 elements long." Not that is unforgiveable!
I agree. There's a time and place for both indexing and pointer access to arrays. In this case, however, the pointer would have been much better and at least, considering the timing constraints, the assembly should have been inspected.
"the assembly should have been inspected" Yes, that's the one sure way to settle it!
View all questions in Keil forum