| ??? 01/06/11 02:39 Read: times |
#180460 - It's about bracketing claims Responding to: ???'s previous message |
Richard Erlacher said:
After all, the guy has made it clear he intends to use a mid-sized 805x and not an ARM or some other larger architecture. Let's leave C++ out of the discussion, then, shall we? It was suggested as outside the scope for 8051 a long time ago in this thread. But should be kept outside the scope for the right reasons. You did write "I wouldn't hold my breath for that to become realistic for microcontrollers." and unless you want to stand up and clain that 8051 is the only microcontroller in existence, then it's definitely not outside the scope for microcontrollers. And don't make it an ARM-only choice either. C++ would probably be great for many of the 16 and 32-bit PIC chips too. Maybe even for some of the largest 8-bit chips. It's just the design of the stack and index features of the 8051 that I don't think it would be a good choice even for the larger 8051 chips. But C++ is very much relevant to debate, since it is so closely based on C. It was originally intended to support any C program, to let the developer change code blocks at their own pace from C to C++. Some of that have broken since the C and C++ language standards have taken some steps away from each other. But it is relevant that someone who do learn C can continue to use C++ later and be able to get access to some of the advantages quite soon. But back to the 8051. C++ as a language can produce the same code for the same architecture as C. So there is nothing that doesn't allow a C++ program on a 4kB 8051 if a C program would work well on the processor. The C++ program could run the same source code, with the addition of having namespaces, static member methods etc. The reason why it isn't so meaningful to use C++ anyway, is that the functin call work-around methods in use by the C compilers means that a C++ developer can't simply make use of virtual method calls (basically function pointers), or references (basically pointer access) without getting hit by hidden costs. Costs that isn't there for most other processors - even quite small. For the "normal" case, C++ is a better C. But for the 8051, you get cheated a bit when large percentages of the improvements makes the code look nicer while making the produced binary worse. Richard said:
I assure you, though, that 'C' is still taught in universities here, and is still widely recommended for PC and MCU applications. And there haven't been anyone claiming that C isn't taught. But C is not taught as an introductory language in computer science. And it is not the most teached language. It may be the introductory language - or even the most teached language - if specifically talking about courses about microcontrollers. It is teached for computer science, but normally to students who have already been introduced to a number of other languages before. It has to be taught, since it is a major language with huge amounts of code (embedded or PC) in active use and under active development. Richard said:
The lack of C++ garbage collection is not something with which PC programmers concern themselves. Yes they do. For the simple reason that they get constantly hammered with suggestions that languages containing pointers, or languages not having garbage collection, does not work. Hammered by Microsoft. Hammered by book authors. Hammered by magazine writers. Hammered that they do care. Even if it simply isn't true. My personal view of "the truth" is that people will fail with any language if they aren't enough engineers to do good work. And if they are good engineers, they will manage well with most languages. But my view doesn't matter much when academy, a large percentage of recent graduates, and some of the largest software houses spreads the claims. That there are economical reasons why corporations want the developers to invest in their new compilers or even in their proprietary software architectures, seldom gets discussed. Richard said:
Moreover, since nearly every drunk on skid-row can program in 'C',[...] The important thing is basically what I did say very early on. "A minute to learn, a lifetime to master." It is very easy to learn C. It isn't easy to write magically beautiful and optimal code. But then it isn't easy in any language. But one reason C is so popular is because it is so easy to get started. Richard said:
BTW, how large is HELLO.C's executable these days? Depends on two things. 1) If user used printf() or puts(). 2) How good the specific compiler/linker is at figuring out what advanced parts of printf() that doesn't need to be linked. An old Keil thread claims 1248 bytes with printf() and 524 bytes with puts(). The later figure trimmed to 486 bytes with linker code packing. But the question is a bit irrelevant since we are not comparing languages but discussing the size of specific features of the runtime library. It doesn't say too much about the growth speed of a program when you add real code lines that performs real work. http://www.keil.com/forum/2741/ Another thing to realize here is that there are a number of people who are happily using C++ on 8051 chips too. I haven't looked at the IAR compiler but only some preprocessor, similar to cfront, that converted C++ to C before using the normal (such as Keil) compiler. I might have felt better about C++ on the 8051 if Keil had had native C++ support. Especially since the Keil compiler actually does a great amount of job all the way down in the linker. |
