Modern compilers are very reliable, that's true. However, there's another thing to take into account (especially on small micros with limited resources): If you don't have the slightest idea of how high-level language constructs map to the target hardware, you won't write efficient code. That might not be a problem when you over-spec the hardware by a magnitude, giving you (or: the tools) plenty of headroom in processing power and memory footprint. It IS a problem though, if you compete with those who did their homework.
Recent I've worked on 80C51 and 80C167 without resorting to learning the processor instructions. The processors fit the application, but I find their instructions to be butt-ugly. I just don't want to learn them, and the C written code works just fine. Of course I know about native types and such. I'm not going to use longs everywhere.
An engineering professor once said it's about _money_. In my case, development speed is important, and I have many other things to do besides program these bit-twiddlers.
This depends on platforms.... Some platforms have some extremely good compilers where the first comment holds true. They also have some downright appalling compilers where the second comment holds.
There are probably some architectures where there are no really good C compilers and the second comment will be proved and the first comment will fail.
No, I am not going to make any suggestions as to which is in which category :-)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
You did notice that I wasn't very specific either.
I do know of one specific compiler that is reasonably good but insists on converting all intermediate computational values to int precision IAW the C standard. This leads to /much/ extraneous code as when char values are extended to 32 bits and then truncated to a byte value on assignment.
I once asked PJPlauger to cite one example of a C compiler that generates better-than-ASM-programmer code. He didn't reply.
It depends on project size... Given big enough project most ASM programmers won't even finish in time :-)
And while waiting for the ASM programmer you can:
Global optimize the code - all code treated as in line if it helps.
Use profile optimized compilation.
Find out your hotspots with profiling - and optimize those (in ASM).
Go fishing :-)
But suppose the ASM programmer uses strict call conventions and other programming rules not to end up in a mess - then he looses some of the 4:1 advantage.
IMHO
Have anyone seen hand assembled SPEC results? (They are close since most uses some strange compilation options...)
Better at what? Generating assembly code from high level statements? Generating object code for user programs that occupy fewer bytes? Generating object code for user programs that execute in fewer cycles? What about library routines? Gonna redo all those by hand too?
Anyway, compiler wins in the 1st case (speed). You just cant type as fast as the compiler. In the second case (size), you might save a few bytes by hand eliminating some extra register loads and saves, but why? The days of counting bytes in a 4k rom are fading fast. In the 3rd case, (speed), if you are only a few percent too slow, I'd say optimizing the algorithm in c will squeeze out a few percent sppedup as well as hand assembly optimization. If you are off by
50% or 100% too slow, you picked the wrong speed processor up front and now you are professionally embarrassed. If you are lucky, there is a faster processor that will run the c program (oops... your program was in assembler for the old slow processor... too bad)
We have a C source as reference for our RTOS, but the real kernel is handcoded (not translated !) in assembly. Depending on the CPU the assembly code is 30% to 10% shorter !
I hear this argument now for 4 years, and still often size matters. Of course, there are more and more embedded systems with megabytes of RAM and ROM/Flash.
Agree, first check the algorithm, even before you start with funny C optimizing tricks.
But having the best (for a given time T) in C, than having a good assembly programmer squeezes another 20% out of it !
If the new CPU does not have the same assembly, than it most likely has also not the same electrical parameters and your lost anyway.
But, to make it clear, I would not write an 100k line C/C++ program in assembly. I am crazy but not that crazy :-)
It is like always, you have to counter balance effort against what you gain.
(Hehe, re-writing winXXXX or linux in assembly would allow you to run it nicely on a 486 I guess :-)
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.