Professional C__ - Marc Gregoire [440]
Mixing C++ with Assembly Code
C++ is considered a fast language, especially relative to other object-oriented languages. Yet, in some rare cases, you might want to use raw assembly code when speed is absolutely critical. The compiler generates assembly code from your source files, and this generated assembly code is fast enough for virtually all purposes. Both the compiler and the linker (when it supports link time code generation like VC++ 2010) use optimization algorithms to make the generated assembly code as fast as possible. These optimizers are getting more and more powerful by using special processor instruction sets such as MMX and SSE. These days, it’s very hard to write your own assembly code that will outperform the code generated by the compiler, unless you know all the little details of these enhanced instruction sets.
However, in case you do need it, the keyword asm can be used by a C++ compiler to allow the programmer to insert raw assembly code. The keyword is part of the C++ standard, but its implementation is compiler-defined. In some compilers, you can use asm to drop from C++ down to the level of assembly right in the middle of your program. Sometimes, the support for the asm keyword depends on your target architecture. For example, Microsoft VC++ 2010 supports the asm keyword when compiling in 32-bit mode, but asm is not supported when compiling in 64-bit mode.
Inline assembly can be useful in some applications, but we don’t recommend it for most programs. There are several reasons to avoid inline assembly code:
Your code is no longer portable to another processor once you start including raw assembly code for your platform.
Most programmers don’t know assembly languages and won’t be able to modify or maintain your code.
Assembly code is not known for its readability. It can hurt your program’s use of style.
Most of the time, it is not necessary. If your program is slow, look for algorithmic problems or consult some of the other performance suggestions in Chapter 24.
When you encounter performance issues in your application, first look into algorithmic speed-ups, and use raw assembly code only as a last resort.
Practically, if you have a computationally expensive block of code, you should move it to its own C++ function. If you determine, using performance profiling (see Chapter 24), that this function is a performance bottleneck, and there is no way to write the code smaller and faster, you might use raw assembly to try to increase performance.
In such a case, one of the first things you will want to do is declare the function extern "C" so the C++ name mangling is suppressed. Then, write a separate module in assembly code which performs the function more efficiently. The advantage of a separate module is that there is a “reference implementation” in C++ which is platform-independent; and, there is a platform-specific high-performance implementation, in raw assembly code. The use of extern "C" means that the assembly code can use a simple naming convention (otherwise, you have to reverse-engineer your compiler’s name mangling algorithm). Then, you can link with either the C++ version, or the assembly code version.
You would write this module in assembly code and run it through an assembler, rather than using inline asm directives in C++; this is particularly true in many of the popular x86-compatible-64-bit compilers, where the inline asm keyword is not supported.
However, using raw assembly code should only be done if there are significant performance improvement factors. A factor of 2 might justify the effort. A factor of 10 is compelling. A factor of 10% is not worth the effort.
SUMMARY
If you take away one point from this chapter, it should be that C++ is a flexible language. It exists in the sweet spot between languages that are too tied to a particular platform