Using gcc to Assemble Your Programs

Assembly language programs must be translated into machine language in order to be executed. Just as high-level language programs are translated by a compiler, assembly-language programs are translated by an assembler. (The idea is that this is a program that builds or assembles a program from source.)

In addition to the translation itself, the program must be linked in order to construct a final executable file. The linking process combines the machine code produced by the translation with whatever library routines your program requires. In fact, your program may reside in a number of source files, in which case the assembler or compiler will produce an object file for each source file; the linker will combine all these object files, together with the necessary library routines, to yield an executable program.

While you can certainly run the various translator and linker programs you need separately, the easiest way of organizing this process is to let gcc organize it for you. While you may think of gcc as a C compiler, it is able to handle a variety of related tasks.

You can pass gcc one or more source files; for each source file, it will use the file extension at the end of the file name in order to determine what to do with that file. Each source file is translated into a corresponding object file using the appropriate translator programs. As you know, .c files are first preprocessed with the macro preprocessor and the result is then translated into an object file by the C compiler. In similar fashion, .S files are preprocessed first and are then translated by the assembler into an object file. Files with names ending in .s are not preprocessed first; they are just translated by the assembler into object code.

You can include one or more source files in a single gcc command, and you are free to mix C and assembly-language source files. The starting point of your program is at the address called main. You should have exactly one definition for main in exactly one of your source files. If main appears in C source, it is a C function, as usual; if main is in assembly source, it should appear with a colon after it as the label of your main function.

You can write assembly language source files using vi or your favorite text editor. Just be sure that each assembly language source file has a name ending with ".S" or ".s" (depending on whether you use any preprocessor features, such as #define's, or not).

Specify the name of your desired executable file using the -o option to gcc. After this executable is created, you can type its name on the Unix command line to run it.

For example, a program written in a single assembly-language file (without using macros) could be assembled and linked with the command:

For a more complicated example, supposed you had a program that you had divided into two C source files hellomain.c and helloauxiliary.c, plus four assembly language files fastgraphics.s, interrupts.s, mouse.S, sound.S. As the names imply, the latter two assembly language files make use of the macro facilities, but the first two do not. You want to produce an executable program called hello. This could be done by entering the command

Something else you can do with gcc is to take a C source file and do a partial compilation, just translating to assembly language (but not going on to machine language or to the linking stage). To do this, you use gcc with the option -S. For example, if you have a C program named something.c, you can use the command

Keep in mind that there are many different ways of expressing a given C source file in assembly language; the gcc -S command will just show you one way of doing it. This may well not be the "best" way of writing the assembly language code; it is very unlikely to be a particularly fast or short program if you don't use any of gcc's optimization options. The resulting code, although generally not tricky, may be hard to read for a few reasons:

• The compiler may need to invent labels to use (which won't be meaningful English words, of course).
• The compiler is following very general rules for carrying out the translation; this doesn't necessarily result in short or clear code in any particular case.
• The code may be somewhat long-winded -- for example, moving things from register to register unnecessarily -- if you're not using optimizations.