Reasons you should NOT use inline asm
While the power and flexibility of inline asm can tempt people to experiment, it should be remembered that there are a number of reasons to NOT use it in real world applications.
1) It is tricky to write correctly.
Even for people experienced in working with gcc's inline asm, it can be very tricky to get things exactly right. Even 'minor' mistakes like failing to clobber memory or earlyclobber a register can result in problems that may not show up until well after the asm has been executed. And examining the asm output during a compile (-S) doesn't guarantee that the inline asm was written correctly either, since small and (seemingly) unrelated changes in surrounding code might someday cause the compiler to resolve the constraints differently.
2) It is difficult to maintain.
C programmers are relatively plentiful these days. But people comfortable with asm are rarer. When also weighing in the complexities of gcc's extended syntax, you can end up with blocks of code that maintainers don't understand and are afraid to touch. This can be a problem if the code is no longer optimal (or even correct), since people might not even realize it.
3) It is not portable across platforms.
By definition, assembler instructions only work on specific CPUs. When your application is ported to another platform, the inline asm will need to be re-written, not just re-compiled (as the C code can be).
4) It is not portable across compilers.
There are no C standards that define the semantics of inline asm, so different compilers can and do handle it differently. This can result in code that compiles without error under different compilers, but produces subtly different results.
5) See How to Convert Basic asm to Extended asm for reasons not to use gcc's Basic asm.
6) Performance may not be what you expect.
Just because code is written in assembler, that doesn't (somehow) make it magically faster than code written in C. And writing a simple test harness to time a routine with asm vs c code can miss some important considerations:
- gcc has no idea what your asm does. This means it can't interleave/reorder instructions into (or out of) your block (think: pipelining). It also screws up the compiler's ability to optimize the surrounding code.
- In order to free up the registers used by your asm (especially if specific registers are required), the compiler must either forego using those registers for other (possibly more beneficial) purposes, or incur the expense to save and restore them.
- Improvements in new versions of the compiler might generate the same or even better asm than the hand-written code.
- Variations in how different processors handle assembly can mean that code that runs better on one processor may be slower on another.
- Obscure implementation details can bite you in the asm: For example an asm that has 2 outputs is (currently) optimized differently than an asm with 1 output, even if the second output is never used.
- Using inline asm disables the compiler's ability to compute constant values.
That's not to say that there are no reasons to use inline asm
A) For performance.
After performing live testing on your entire application on a variety of supported CPUs, if you find that there is an improvement in performance that is large enough and important enough to outweigh all the reasons not to use it (and using an actual asm routine does not help), then inline asm can make sense.
B) To access CPU-specific instructions.
It is possible that the reason gcc isn't generating the specific instruction you expected is that it is known to be slow, problematical, not supported on the processors you are compiling for, etc. But if there is a reason you need a specific instruction, gcc has builtins for many of the more useful ones. Using these in preference to inline asm allows gcc's optimizers to produce better code. However it is possible that an instruction is new enough or obscure enough that there is no builtin for it.
C) To emit asm directives.
Under (seriously) obscure circumstances, it can be useful/necessary to emit directives to the assembler for sectioning, macros, etc.
D) Accessing non-standard calling conventions.
While the calling conventions for a particular architecture are generally well-known and well-followed, it is possible that it is necessary to call code that uses some custom calling convention. It might make more sense to write a wrapper in assembly that performs the necessary translation instead of using inline asm.