Keil C vs. Bascom basic compiler

Jon,
Here's a suggestion for the manual.
How about adding a note to the printf page, pointing out that puts/putchar use much less code memory for simple output.

Dave,
I can't see anything wrong with Hans's description. What he describes happens at compile time. His third point was that if the compiler sees a non-constant string anywhere in the code, then it gives up trying to optimise, and uses the full-featured version of printf().


Hmmm.. okay, I went back and re-read the post that I (somewhat snippily) replied to, and I agree that it's technically possible. However, this feels like something that should be taken into account and compensated for (if necessary) on the application side rather than the tools side. If you start building this level of "special case" consideration into the toolset, you'll wind up with Win51, the first 32-bit (!) GUI OS for embedded 8051 applications, and I, for one, would rather skip that particular nightmare. Not to mention the extra development effort and cost and the price point impact it would no doubt have.

IMHO, of course. You could also argue that this is the whole point of having an optimizer.

It's late. I give up. =)

- Dave

Nice job comparing SIEVE in both compilers. You now know whay I did the first post. But I didn't measere execution time.

Where is the swith for linker code packing ?

I make another threed post, where I looking Libraries for smart cards (eg. SLE4428). Anyoone help since this is most 'live' thread ?

Mladen Bruck

"Where is the swith for linker code packing?"

It's in the "Options for target" -> "C51" tab.

Stefan

Erik,

"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"

Not at all. Most of the 8051 stuff I work on is battery powered. Power consumption is of paramount importance - we use very low clock speeds and keep the CPU in idle mode >95% of the time. Maximum code space is 16k. Some aspects of data acquisition and output require very accurate timing. I spend a considerable amount of time making code as efficient as possible both in terms of speed and size.

I don't use an RTOS - but I wouldn't hesitate to do so if it were beneficial to the project and feasible in terms of size and speed. I don't use C++ - but again I would readily do so given the above provisos.

The constraints of the operating environment mean that we have to use a microcontroller rather than a microprocessor. The software needs to do a lot of complex floating point maths and give formatted output via the serial port. It achieves all this in a timely and efficient manner using printf() and the Keil floating point library. The microcontroller turns out to be perfectly suitable for a job that you seem to think is only suited to a microprocessor.

My point is really this:

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. 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.

Stefan

"And...with linker code packing...

Keil (using putchar and puts and linker code packing):
Code Size: 486 Bytes
Execution Speed: 6.330105 Seconds"

Jon,

That's very interesting. What optimisation level did you use?

Stefan

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

What optimisation level did you use?

The very highest one I could - 11.

Jon

Where is the swith for linker code packing?

The Use LX51 Linker must be enabled as well.

Jon

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...! ;-)

"What optimisation level did you use?

The very highest one I could - 11."

I'll bet you could shrink it a bit further using level 9.

Stefan

"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?!

"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?!

Of course you are right; however obfusciated assembler is a lot easier to decipher than morphed, encapsulated and whatever C++. The point I am making is that the more "abstract" the language allow you to be, the easier it is to hide what it is you are doing (just compare an abstract painting to a naturalistic). Thus a C++ programmer has to be extremely conscious of the maintainability of his/her code more so that utilizing all bells and whistles the language allow and I have yet to see C++ code written expressly for maintainability.

Show me that a majority of C++ programmers are writing code expressly for maintainability (no babble about safety from encapsulation and all that other hype) and I may change my attitude about that language.

Erik

"Of course you are right; however obfusciated assembler is a lot easier to decipher than morphed, encapsulated and whatever C++."

Not for those of us who are used to using these new-fangled high level language things!

"The point I am making is that the more "abstract" the language allow you to be, the easier it is to hide what it is you are doing"

Exactly!

"Thus a C++ programmer has to be extremely conscious of the maintainability of his/her code"

Maintainability is one of the strong points of C++. I'd say that well written assembler is more difficult to maintain than poorly written C++. As an amusing excercise try translating a few lines of an assembler program as directly as possible into C on a line by line basis. Once you remember what a lovely and incredibly useful keyword 'goto' is you'll make progress.

"Show me that a majority of C++ programmers are writing code expressly for maintainability"

Of course they aren't, they're writing code to produce a working product. Maintainability is just one of the many side benefits of using C++.

"(no babble about safety from encapsulation and all that other hype) and I may change my attitude about that language"

You can't expect us to expalin the benefits of a language with the proviso that we ignore the features that provide the benefits!

Erik, you just seem to think that your way is the only way, and you're going to hang on to it at any cost. Good luck!

Stefan