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 !
This is getting kind of silly. If anyone uses Printf for anything but debug, they are writing "PC code". If "PC code" is employed all bets regarding code size is off as should be by Mr. Gates decree. C51 and its cousins are thankfully optimized for "embedded code" which is what the '51 and derivatives are intended for. Erik
I faced a problem of having a project which had to include some 'reference code' that could not be changed. Of course, it was full of printf() statements. My solution was to write my own printf() function that included just the required features. This also gave me the opportunity to add in some non-standard features that I found very useful and further reduced overall code size. My user_printf() function is a bit big to post, but if you want a copy I can e-mail it. Please post your e-mail address if you are interested.
"This is getting kind of silly." You're telling me. "If anyone uses Printf for anything but debug, they are writing "PC code"." Actually, a lot of us are using printf() or sprintf() in our embedded firmware - if you have a lot of formatting to do it would be stupid to do anything else. If there is enough code space to use it for debugging, why not use it for release code? "If "PC code" is employed all bets regarding code size is off as should be by Mr. Gates decree." printf() rather predates Microsoft's grip on the world. "C51 and its cousins are thankfully optimized for "embedded code" which is what the '51 and derivatives are intended for." Indeed, but when the 8051 wants to communicate through its little window on the world it may need to do so in a format the user can understand. That's where printf() comes in. Don't tell me you're a subscriber to the 'Real men code in assembly, C is for boys' philosophy? Maybe it's time to drag yourself into the 21st century. Stefan
"I faced a problem of having a project which had to include some 'reference code' that could not be changed. Of course, it was full of printf() statements. My solution was to write my own printf() function that included just the required features." I'm curious about this - if you replace the library printf() calls with your own version of printf() you have modified your reference code. Stefan
Indeed, but when the 8051 wants to communicate through its little window on the world it may need to do so in a format the user can understand. That's where printf() comes in. NO communication to "the real world" need be that complicated, if it is the maybe some post-processing at the receiving end would be an idea. Don't tell me you're a subscriber to the 'Real men code in assembly, C is for boys' philosophy? No, I am not; however I do belong to the "the '51 is not a PC club" Erik
Hello ! My first intention was to find someone to help. You are going in oposite direction. After all this posts you make, I see that I can use both printf and pust. It only how much code I have in microcontroler. since I used AT89C8021 it was painful to spend 1 Kb. But, when I use some bigger (8252) maybe I will use printf. As long as I have enough code. Best regards ! P.S. what is best, I found perfect place for resolving some problems, since I am new in C for embeded applications. Thanks again.
Mladen, If I were in your position I would take Graham Cole up on his kind offer to send you his function user_printf(). It may be a good fit for your application as is or you might be able to strip it down even more.
"NO communication to "the real world" need be that complicated, if it is the maybe some post-processing at the receiving end would be an idea." Post processing requires software. Formatted ASCII data can be viewed or logged to disk by any terminal emulation program. That saves work. "No, I am not; however I do belong to the "the '51 is not a PC club"" So the fact that the 8051 is not a PC means that if you do use a (relatively) high level language such as 'C' you must avoid using some of the most powerful library functions - why? Because it somehow isn't proper? Stefan
To mr. Graham Cole ! Please send me your custom print() function. And some explanation how to install it and use. With regards ! Mladen Bruck
I will need your e-mail address.
Ops ;) mladen.bruck@pincom.net
So the fact that the 8051 is not a PC means that if you do use a (relatively) high level language such as 'C' relatively high? what about efficient. Because it somehow isn't proper? The next we will see is "just add a megabyte of ROM and you can do the proper thing and use C++" Erik
"relatively high? what about efficient" 'C' is relatively efficient. What's your point? "The next we will see is "just add a megabyte of ROM and you can do the proper thing and use C++"" You already can use C++ without adding a megabyte of ROM. Perhaps you should try it? Stefan
Stefan, Nothing personal, but you come across as a "if it is too slow buy a faster (more expensive) processor, do not try to streamline the code, it may make it not proper" person. We are discussing the difference between a microcontroller and a microprocessor related to purpose, use, functionality and application. I have worked with "real C" programmers and they professed that there was no need whatsoever to understand the purpose of the equipment such as no C++ for low cost or ultrafast response. I once revised a development where a bloated RTOS with some "real C" code bugged the processor so far down that the "real C programmer" suggested a change to an ARM processor. It took about a month to get the bloatings out of the code (still using C) and then the '51 was more than sufficient. Re C++ you need to read this interview http://www.ganssle.com/tem/tem17.pdf Trevlig kvaell Erik
You can write bloated code in any language, including assembly. You can write "efficient" code in C, and yes, even in C++ -- if you know what you're doing. C++ in particular is more subtle and thus more difficult than it seems on casual inspection. The smallest overall program is not necessarily one where individual basic blocks are the smallest.
You can write bloated code in any language, including assembly. I agree; however it is a characteristic of "real programmers" as opposed to "embedded programmers" to concentrate on the elegance (in their opinion) and state of the art of the code rather than the efficiency. I consulted for a while with a major cellphone company and the "real programmers" decided to go to C++. This led to the need to double the clockspeed of the processor. Before this happened I said, wrote and almost screamed "faster clock is more battery usage and one of the problems we have is is battery charge life". They went ahead anyhow "because it is the right thing to do" and now the lack of battery life has led to a sharp decline in sales for that company. Erik