5.1 Subroutine calls  (Page 3/3)

in your file, getchar is replaced with a macro definition at compile time, replacing the C library function.

You can make cpp macros work for FORTRAN programs too. Some programmers use the standard UNIX m4 preprocessor for FORTRAN For example, a FORTRAN version of the C program above might look like this:

Without a little preparation, the #define statement is rejected by the FORTRAN compiler. The program first has to be preprocessed through cpp to replace the use of AVERAG with its macro definition. It makes compilation a two-step procedure, but that shouldn’t be too much of a burden, especially if you are building your programs under the control of the make utility. We would also suggest you store FORTRAN programs containing cpp directives under filename.F to distinguish them from unadorned FORTRAN. Just be sure you make your changes only to the .F files and not to the output from cpp . This is how you would preprocess FORTRAN .F files by hand:

The FORTRAN compiler never sees the original code. Instead, the macro definition is substituted inline as if you had typed it yourself:

By the way, some FORTRAN compilers recognize the .F extension already, making the two-step process unnecessary. If the compiler sees the .F extension it invokes cpp automatically, compiles the output, and throws away the intermediate .f file. Try compiling a .F on your computer to see if it works.

Also, be aware that macro expansions may make source lines extend past column 72, which will probably make your FORTRAN compiler complain (or worse: it might pass unnoticed). Some compilers support input lines longer than 72 characters. On the Sun compilers the –e option allows extended input lines up to 132 characters long.

Procedure inlining

Macro definitions tend to be pretty short, usually just a single statement. Some- times you have slightly longer (but not too long) bits of code that might also benefit from being copied inline, rather than called as a subroutine or function. Again, the reason for doing this is to eliminate procedure call overhead and expose paral- lelism. If your compiler is capable of inlining subroutine and function definitions into the modules that call them, then you have a very natural, very portable way to write modular code without suffering the cost of subroutine calls.

Depending on the vendor, you can ask the compiler for procedure inlining by:

• Specifying which routines should be inlined on the compiler’s command line
• Putting inlining directives into the source program
• Letting the compiler inline automatically

The directives and compile line options are not standard, so you have to check your compiler documentation. Unfortunately, you may learn that there is no such feature (“yet,” always yet), or that it’s an expensive extra. The third form of inlining in the list, automatic, is available from just a few vendors. Automatic inlining depends on a sophisticated compiler that can view the definitions of several modules at once.

There are some words of caution with regard to procedure inlining. You can easily do too much of it. If everything and anything is ingested into the body of its parents, the resulting executable may be so large that it repeatedly spills out of the instruction cache and becomes a net performance loss. Our advice is that you use the caller/callee information profilers give you and make some intelligent decisions about inlining, rather than trying to inline every subroutine available. Again, small routines that are called often are generally the best candidates for inlining.