Compilers
Bama has a large suite of compilers, including Fortran 77, Fortran 90, c, c++, and Pascal, and supporting software. In addition there is the GNU c compiler. For writers of small programs a simple knowledge of the compiler commands might be sufficient but there is a great deal more help you can get from the supporting software. There are options and routines to help you debug your programs as well as routines that will help you create a lean, mean, fast running executable or even an executable that will use parallel processors since Bama is an 8 processor machine (more on these routines later). There are also routines that will help the writer of a large program consisting of many subroutines keep track of changes throughout the program and keep all the subroutines recompiled and up to date as changes are made (called "make"). There is even a utility which can be used when a software package is being written by a group of developers whereby they can "check-out" a software subroutine to work on and no else can come in and change things for the time it is checked out First let's look at some simple compiler commands. The command to call each compiler is in the table below. Users who are more familiar with Unix can do a "man" on the compiler name for lists of all the available options. In their simplest form the use of the compilers all look quite similar.
Compiler Name |
Fortran 77 |
Fortran 90 |
C |
Gnu c |
C++ |
Pascal |
|---|---|---|---|---|---|---|
Command |
f77 |
f90 |
cc |
gcc |
CC |
pc |
Preferred Suffix |
.f |
.f90 |
.c |
.c |
.c |
.p |
So, to compile and link a Fortran 77 program called "program.f" you would give the command
f77 program.f -o program
The "-o program" switch asks that the output executable be called "program". If there were no error messages then the file could be executed with
./program
Larger programs are often split up into separate files with each containing a separate subroutine. These can be compiled just as easily with the command
f77 main.f sub1.f sub2.f sub3.f -o main
Where "main.f" is the main routine and "sub?.f" are the various subroutines.
At this point, the routine "make" becomes very helpful. Often with a program split like the above example, you might want to recompile just the subroutines that have changed and relink (thus speeding up this step). The program "make" can keep track of which routines need to be updated and will arrange for only those to be recompiled before it relinks the entire program. A full discussion of "make" is not included here but you can get the information from the man page on "make".
When subroutines are put together in a special file called a library, such as with the "ar" command, they can be accessed with a special switch which gets passed on to the linker (called "-l"). Suppose the library is called "mysubs.a" (a typical naming scheme). You could include these libraries in your compiler statement with
f77 main.f -o main -lmysubs.a
Programs can often have errors in the logic which get referred to as "bugs". This is where debugging software comes in handy. There is a simple debugger called "dbx" which you can use to run through your program step by step to see where it fails. The fancier debugger is run under X-windows as part of the "workshop" suite of programs.
Before any debugging can be done, the program needs to be compiled with extra information included for the debuggers to use. This information gets included with the "-g" switch. So our first simple example would look like
f77 -g program.f -o program
To increase the speed of larger programs you need to know where the program spends most of its time as it executes. You then can work to streamline that section of code first to get the best improvement. Learning how the program spends its time is called "profiling". To prepare for profiling you would use the "-p" switch and then use the "prof" command (or "-pg" and "gprof"). There is also a profiler in the "workshop" suite that was mentioned above. You can include both profiling and debugging if you like. Again go to the man pages for more help.
f77 -g -p program.f -o program
Even without putting the work into profiling a program you often get a performance boost by turning on optimization. This is incompatible with "-g" so this is usually done when all debugging is complete. To increase the optimization you can use the "-On" switch where "n" is a number from 1 to 5. You can also specify more precisely the type of machine on which you are compiling so that the compiler can make some smart choices about what to do. Two such options are "-fast" and "-xtarget=entr6000". When optimizing it is best to run the program with none turned on to verify the correct output, then to continue to turn on more optimization options and check how they affect the speed, but also to watch that they don't negatively affect the output (which can happen). You can profile to check whether the performance has been improved by the optimization you have used.
For more information on all this and for advanced such as parallel processing we refer you to the man pages for the compiler you will be using and to the online documentation for the compilers which is located at
http://www.bama.ua.edu/workshop
© 1998, The University of Alabama. The information included here is for the University of Alabama central computing facility as it was configured on the document date. It may or may not apply to other Unix systems.