Hello ! I have a problem which I can't resolve. I wrote program for 89C2051 for one of my friend in Basom Basic compiler (http://www.mcselec.com). Compiled code was about 1945 bytes. Since I prefer C, I transalte Bascom basic to C. But when I compile, generated code was 2313. I try to change optimization parameters, but generated code never go below 2313. Even bigger. Where am I wrong ? Is it possible that stupid Basic make smaller code tne best C compiler ? Then I find out that this code: while (1) { printf ("Hello World\n"); } generate fully 1093 bytes (!) for Atmel 89C2051. 1093 bytes???? Three lines? Same program in Bascom generate only 154 (!) bytes. When I remove all "printf" from my C code, generated code was arond 2200 byte. But, with same action in Basic code (remove all "print") 1340 bytes long code. Exactly same program in Keil C and Bascom basic generate 860 byte smaller code ! I don't belive this. Do I have to program in (stupid) Basic if I want smaller code ? I still belive I did mistake somewhere, so I need help. I will send both C and basic code for interested people. With best regards !
If tools are available that are beneficial to the project then use them. Don't rule things out merely because you've decided at some time that they are not appropriate. Stefan, You are thinking development, I am thinking end product. Using a bit of assembler I managed to change a product so that it could be manufactured for $1.83 less. That does not sound like much till I tell you that 500.000 were made. A modern C compiler can make code very close to (sometimes better than) a seasoned assembler programmer and for code that does not utilize special functions of the hardware C is, indeed, my choice. The REAL problem with C and more so with C++ is that it allow the programmer to obfusciate the code to a level where no single soul can figure out what happens. I have seen 500 character long if stetments. The worst about C is that it is stated to be "self documenting" I would rather buy swampland in Florida than attempt to read C code by someone that believes that. Stefan, I believe very much in "the right tool for the job" and my products now vary from 99% C and 1% assembler to a speed demon that is 25% C and 75% assembler. I have yet to see ANY C++ code that is maintainable and efficient. There is no way anyone is going to convince me that code that inherits and morphs is going to be more maintainable than code that does not. There is no absolute divide between controllers and processors in much the same way that there is no absolute divide between what is and is not suitable for use on each device You are right; however, if you program a microcontroller as a microprocessor and tell me that is the right thing to do, you better have some very good reason. You state about 5 levels into this discussion that you are doing the above for battery life reasons. I can accept that easily enough, but initially you stated it as a global right thing to do, which I can not agree with. Erik
I use C because I can crank things out very quickly. Often in a matter of minutes. This allows me to test and prove ideas and algorithms quickly. And, with the significant reqources available (examples, forum, and so on) C on the 8051 is pretty hard to beat. I mean with google and this forum, I rarely have to post questions asking for things -- I just have to be really, really good using the search tools that are available. Once everything works (or mostly works) I can start optimizing for speed. This is where I use the profiler to figure out where most of the program's time is spent. There's no need to speed up something that's only invoked a few times. Speed-up the stuff that's invoked a thousand times. I usually start optimizing for size from the very beginning. If I know that I'm size limited, I try to figure out what is the biggest memory hog that I'll have, is it data, long term storage, constants, code, or ???? Once I know what the big memory space killer is, I work on reducing that first. Then I work my way to the second biggest, and on down the line. Jon
"There's no need to speed up something that's only invoked a few times." Unless, of course, those few times happen to be in the critical path on which the whole system depends...! Just goes to show that all generalisations are bad...! ;-)
"The REAL problem with C and more so with C++ is that it allow the programmer to obfusciate the code to a level where no single soul can figure out what happens" Oh yes - this is definitely true. However, I can't see that the same is any less true in Assembler. I think the problem here lies in the programmers - not the language?!