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]
considering the timing constraints, the assembly should have been inspected There's the real chestnut: if, and only if timing constraints apply, should the assembly output by the compiler routinely be inspected (or the relevant piece be written in assembly right away). As D.E. Knuth so famously put it, "Premature optimization is the root of all evil."
"There's the real chestnut: if, and only if timing constraints apply, should the assembly output by the compiler routinely be inspected" (my emphasis) True - since the whole point of writing in 'C' is to improve programmer efficiency. However, I think the point of the original rant was as a training excercise, rather than a routine for experienced C51 developers?
However, I think the point of the original rant was as a training excercise, rather than a routine for experienced C51 developers My 'rant' is that so many just whack the code in and the come here to whine "it does not fit" or "I get this error". Then when we reply "did you read the manual" or "did you take the many memory areas into consideration" back comes "you stupid idiots, I need an answer, not reading" and even worse "I know that when writing in C there is no need to understand the processor" This comes back to the subject of this thread, "to code C for the '51 you need to understand the '51" or as my brother in law would say "it ain't no PC" Erik
For the most part I'd agree with all of these posts. While you won't see me digging through the assembler listings for everything I write, there is a lot to be learned by examining the compiler output. The only way to write fast, efficient code in a high level language is to know what the compiler produces as a result of your code. This isn't specific to the 8051 at all - it applies to every compiler for every processor. If you're interested in speed and efficency you have to know what the compiler generates - period. In defence of some of the silly questions, there are lots of good reasons for them. If you're like me you get handed projects that need to be completed in what is often an unreasonable timeframe. You do a quick search through manuals and PDF files but don't find the answer, so you ask here. Often the answer is in the documentation somewhere - if you can find it, and you have the time to find it. If it's a simple thing, and you KNOW someone out there has the answer right in their head, then it's more cost effective to just ask. I had one guy working for me who was determined to figure out a problem by himself even after I told him to call tech support (which we paid for). He bugged me about it so I took a quick look and told him I thought he had mis-configured the address mapping (ST10F269) but to call support if he didn't resolve it in a day. He screwed with it for three weeks before he called support. They got back to him the next day and told him how to configure the linker. I don't need to tell you he doesn't work here after that episode. The moral - don't *** at these guys or give insulting answers. Help them (give them the answer if you have it - not the manual section) and nicely point out where they might have found it - next time they'll look. Being a mentor means you help people - not ridicule them. It's a lot better to be a hero than an A-hole.
don't *** at these guys or give insulting answers. Help them (give them the answer if you have it - not the manual section a comment on this by two examples: If someone in the question makes it obvious that (s)he is familiar with the basics I believe an answer is forthcoming every time. Answering someone that does not know what IDATA means with a direct answer (it is...) is not a help. Such questions are, and should be, referred to Please read the manual. At that level only a study can bring about enough knowledge to even manage to get by. The above just, once more, states the theme of this thread "if you do not want to familiarize yourself with the '51 - do not use it" Erik