No. What you did say was: "I have said that one who can't program in ASM can't program."
A developer can look at number of assembler instructions generated for a couple of C lines and learn what is expensive and cheap, without knowing how to write these assembler instructions. A developer can use an oscilloscope or a simulator to measure the running time of a piece of C code and learn that one C construct runs faster than another. General knowledge about how hardware works helps a lot. Actual knowledge to write assembler is often not needed, since so huge percentage of all embedded application code can be written in C and work well, work with an affordable processor, consume acceptable amounts of flash and RAM, consume acceptable amounts of power, ...

You live your whole life thinking how good you are to know about clock cycles for 8051 chips. But you are all the time missing that PC-class developers working on compilers or drivers for bigger processors works with complexities many orders of magnitude harder than the 8051 can supply you with. People writing hardware drivers in C or C++ for most modern operating systems need also care about caching, pipe stalls, address translations between user and system space, concurrent execution within one thread and between multiple processors/cores, DMA transfers, access rights, ... If such a person would write a 8051 program in C, you would go for your standard "they don't know how to program!" because they may not know how to write that program in assembler. They would be bright enough to learn assembler, but they would most probably also be bright enough to manage to write a well working program without learning assembler.



About 36 hours before your post, I did write "C++ isn't really applicable for a 8051 chip, even if there are solutions that do support a subset of C++." in the following thread:
http://www.8052.com/forum/read/167501

But you are now doing the standard noob error. You are questioning without bothering with Google. Just writing "8051 C++" as search expression in Google, you would have known about the Ceibo+Keil C51 combo - presented as news on this very forum about seven years ago. You would also known that IAR has a C++ compiler.

The next big problem is that whenever you get just a slightly bit cornered, you decide that anything not related to 8051 is not embedded, in which case it is absolutely forbidden - on your eyes - for a sentence "A huge percentage of all embedded work is now done in C or C++." to relate to anything but the "Richard" projects contaning an assembler loop emitting memory accesses for an external hardware to step through a memory chip and emit table lookups.

But if you can write: "This is the 805x forum and not that for ARM, MIPS, or some other architecture.", how can you directly in the next sentence switch view and write "If you think HLL's are the be-all and end-all, just consider that those crappy cellphones that barely work much of the time, are glued together with other features, e.g. camera, etc, that don't work all that well either, are very likely all programmed in HLL's." Or did you actually think that the bugs you see in your cell phone is the result of a lousy C program running in an 8051 processor?

If you had followed this debate with open eyes, you would know the reasons for the bugs in our mobile phones. We developers are the weak link. Not because we are bad programmers, but because we are not fast enough. We don't have a chance to write the software in assembler. Our productivity when using C is higher. Our productivity when using C++ is even higher (but now we are not talking about 8051 chips, so you can close your eyes). But we are still not fast enough compared to the progression on the hardware side. When using C++, you get a mobile phone with much features for a low cost. But it will have bugs. When using assembler, you get a mobile phone with a extremely high price (and late delivery) - or very little features - and it will have bugs. The problem here is that the marketing division needs to release product A so they can start planning the fair exhibit materials for product B. The code in a mobile phone is huge compared to anything you have been close to. If you have 100 concurrently working developers, you get problems with efficient interfacing of the developers and of the modules written by each developer. C wins many times over assembler. C++ wins over C. But it is still not enough. We, the end users, expects the next mobile phone to be able to match all features from our previous phone, and add something new. But we do not expect the development time for the next generation to take longer than the previous. There just has to be a new flagship released every 12 months. And since you regularly needs to replace the hardware, you would have to start from scratch if using assembler. Assembler reuse when moving to another processor architecture is hard even if it is just an improved core based on the previous core.


Wonderful view. In your view, PI is total crap, since no one has ever managed to get it absolutely correct. Not only that - it has been proven that it has an infinite number of non-repeating decimals so it can't be represented exactly as a quota either.

The debate was about - you do remember your arguments? - lazy developers not using fixed point because they assume that the processor has floating point. A single-precision floating point number has terrible precision. A double is better, but will still store most values as approximations. Fixed-point can match these approximations. A "normal" developer can't extend the number of value digits in a floatint expression. A "normal" developer can use fixed point to produce solutions where the floating point-based algorithm will not converge because of lack of precision.


And why would I want to do the reverse, and fiddle with a prime in non-integer format? They are expected to be integers, so no fp or fixed point needed. Just pure integers.


There are a couple of Pascal compilers that can be used for embedded work, but few developers are doing embedded solutions in Pascal. Most who do are hobbyists who haven't been able to afford the Keil C51 compiler. There are the BASIC Stamp and a couple of other variants, but no serious developer would bring in BASIC in a debate of professional embedded software. I haven't seen much use of FORTRAN in any embedded environments. And it is an ancient language lacking most of the improvements required to be economical to use. I did look at running a FORTRAN signal-processing library in an embedded Linix-based system for a customer, but that isn't applicable since Mr Richard so clearly objects for anything not 8051 being mentioned on this forum or in the same breath as the word "embedded".

The question here: Have you really, really looked at real embedded C programs written by real experienced developers? Next question: Did you understand them? A big issue here is that it hasn't been established that you can read C code and understand it. And next step: Can you produce professional C code for embedded use? For all we know, you may not be able to write a "hello world" in C. To spend significant time comparing the good or bad with using C instead of assembler or assembler instead of C would require that you are fluent with both. Your hostility of anything related to C without supplementing it with real examples doesn't tell much about your true knowledge level about C.


Spam - or marketing in general - has a tendancy to market very unbalanced machines since they know that the majority of buyers are stupid. But you still chose to ignore my arguments. A developer who is experienced now, did get his education a number of years back. And a school normally don't regenerate their full set of machines every year. You are aware that the traditional 32-bit Pentium will support about 3GB of memory when running Windows? The actual processor has - besides the 32-bit addressing - a couple of extra pins to specify supervisor mode or debug mode, so it is possible to address more than 4GB but that isn't something Windows supports. So having a machine use 8GB of RAM requires a 64-bit processor and 64-bit Windows XP, Vista, Linux, ... They have been available for a limited time, which does affect the amount of experienced developers who could have used them during their education. The next alternative was that the students did use non-PC hardware, when doing courses in distributed computing, massively parallel machines etc. Probably not the students who would be interested in comming here to this forum and disturb your day by asking questions about lowly 8051 processors.