Post by thread:C vs. assembler (was: PIC "C" Compilers......)

>> We regularily win with compiled C against hand written assembler. The >> difference is the compiler doesn't foprget a programmers trick. >> >> Walter Banks >Yes, but after looking at your output and remembering the trick I can >write assembler code that will at least tie it and probably beat it. >(After all, I know more info than the compiler.) > Never ending C vs. assembler battle... Despite of all the counter-examples anyone has or will post, I agree with following text (found at the Fast Forward Engineering answer page) 5a. An excellent C compiler can generate better code than an excellent assembly-language programmer, because the compiler can safely generate incomprehensible, non-maintainable, "brittle" code that the programmer wouldn't dare write. 5b. An excellent assembly-language programmer can write better code than an excellent C compiler, because the programmer can see a much larger picture of the problem than the compiler can. And maybe one more point - if any of the two languages was better in all cases, then how would you explain, that the other one still survives ? Regards Josef

> Never ending C vs. assembler battle... Despite of all the counter-examples > anyone has or will post, I agree with following text (found at the Fast > Forward Engineering answer page) > > 5a. An excellent C compiler can generate better code than an excellent > assembly-language programmer, because the compiler can safely generate > incomprehensible, non-maintainable, "brittle" code that the programmer > wouldn't dare write. > > 5b. An excellent assembly-language programmer can write better code than an > excellent C compiler, because the programmer can see a much larger picture > of the problem than the compiler can. I would rephrase these slightly: [1] Given sufficient effort, a proficient assembly language program who puts code size or execution speed above all other concerns (such as maintainability) can produce smaller or faster code than a compiler can write. Such code may require major reworking for even "minor" changes, but in applications where a 10% reduction in code size can save a few cents each on 100,000 units such code may be worth the time and hassle required to produce it. [2] In many embedded applications, there is a level of code size and speed which is "good enough"; any improvements beyond this point serve no useful purpose. A programmer writing in C and using a decent compiler can often produce "good enough" code with less effort than an assembly language programmer. [3] Many programs spend 90% or more of their time executing a very small part their code (5-10% or less). Even small improvements in this part can yield big improvements in performance. Fortuitously, it is often such small pieces where hand-assembly significantly beats compiled code; one game I wrote for a PC had about 100 lines of assembly (about 60 real instructions) and a couple thousand lines of Pascal. The assembly code took about 80% of the program's execution time, and was about 30 times as fast as what the compiler would have produced. As a result, a game that would have run about 2 frames/sec if it were all in Pascal instead ran at 60. > > And maybe one more point - if any of the two languages was better in all > cases, then how would you explain, that the other one still survives ? > > Regards > > Josef >

And maybe one more point - if any of the two languages was better in all cases, then how would you explain, that the other one still survives ? Please repeat to yourself, over and over again until you are convinced, "having the fastest possible most efficient code is not always important." As an extreme example, I think I can state "assembler is always faster than interpretted pbasic" without much fear of contradiction. That doesn't mean that there is no reason for the basic stamp to exist... Sometime, I shall have to tell you all my views on why cisco had to abandon horizontally microprogrammed bit-slice microcontrollers as their preferred engine for network controllers. If the reasons aren't obvious :-( BillW