Heater wrote: ↑
Mon Oct 30, 2017 10:30 pm
On the Raspberry I prefer C because one line of C is worth 100 lines of assembler
I guess you might be speaking figuratively there but in case not I have a challenge for you.
Show me one line of normal kind of C code that ends up compiled to 100 lines of assembler.
Yes must have been figuratively.
With the latest gcc you can intersperse the source code lines with the generated assembler so you can easily see how much asm is produced:-
gcc hello.c -S -fverbose-asm -Os -mcpu=cortex-a53 -mfpu=neon-fp-armv8 -o hello.s
This is extremely helpful for finding the relevant bit of assembler too - just search for the C source line.
I program in C because I like small fast code. Apart from the odd bit of inline assembler to exploit a hardware feature (rare, there are usually C intrinsics available) I would not now ever write assembler for speed. The compiler has so many advantages, for example:
1) it doesn't have to worry about portability or maintainability. It just produces code for the current target at the current time, with no expectation that it will ever be moved to anything else or read and debugged by a human.
2) It doesn't get tired. While a good assembler programmer might possibly do well for a few lines of assembler, the compiler will happily produced millions of lines, in seconds, all very highly optimized.
3) Its normal to decompose code into small manageable functions even if they are only used once. These are written and tested separately. The compiler does the exact opposite, and therefore has access to far more optimization opportunities than the human does.
4) There is so much to think about. For example, I suspect most assembler programmers only do simplistic scheduling, even then do they understand the hardware? movt usually depends on a prior movw, but separating them would be a bad idea on some ARM cpu's. The compiler knows it all and gets it right over millions of lines of code.
Back in the day (20+ years ago) if you wanted to write a subroutine in assembler for speed, one method was to write it in C and then hand optimize the assembler produced. If you did that now, firstly you would very likely not find any improvements - leading you to wonder why you don't just leave it in C. Secondly you might even find new optimizations or simplifications the compiler has done that can be applied to the original C (making the C code simpler is always a good thing). Thirdly if you do see anything you can improve, it probably means you have not understood something, or don't know the hardware well enough. Look again, long and hard, and the chances are you will see the compiler was right.
Assembler is great fun to write, but for me, if I want speed, especially for a largish program, I use gcc 7.2 and write C.