1.4.2Compiler dependencies

where object-format is either co , elf , obj or win32 depending on what C compiler will be used. (Remember that the source file must be changed for both Linux and Borland as well.)

1.4.4Compiling the C code

Compile the driver.c file using a C compiler. For DJGPP, use:

gcc -c driver.c

The -c switch means to just compile, do not attempt to link yet. This same switch works on Linux, Borland and Microsoft compilers as well.

1.4.5Linking the object files

Linking is the process of combining the machine code and data in object files and library files together to create an executable file. As will be shown below, this process is complicated.

C code requires the standard C library and special startup code to run. It is much easiler to let the C compiler call the linker with the correct parameters, than to try to call the linker directly. For example, to link the code for the first program using DJGPP, use:

gcc -o first driver.o first.o asm io.o

This creates an executable called first.exe (or just first under Linux). With Borland, one would use:

bcc32 first.obj driver.obj asm io.obj

Borland uses the name of the first file listed to determine the executable name. So in the above case, the program would be named first.exe.

It is possible to combine the compiling and linking step. For example,

gcc -o first driver.c first.o asm io.o

Now gcc will compile driver.c and then link.

1.4.6Understanding an assembly listing file

The -l listing-file switch can be used to tell nasm to create a listing file of a given name. This file shows how the code was assembled. Here is how lines 17 and 18 (in the data segment) appear in the listing file. (The line numbers are in the listing file; however notice that the line numbers in the source file may not be the same as the line numbers in the listing file.)

The first column in each line is the line number and the second is the o set

(in hex) of the data in the segment. The third column shows the raw hex values that will be stored. In this case the hex data correspond to ASCII codes. Finally, the text from the source file is displayed on the line. The o sets listed in the second column are very likely not the true o sets that the data will be placed at in the complete program. Each module may define its own labels in the data segment (and the other segments, too). In the link step (see section 1.4.5), all these data segment label definitions are combined to form one data segment. The new final o sets are then computed by the linker.

Here is a small section (lines 54 to 56 of the source file) of the text segment in the listing file:

The third column shows the machine code generated by the assembly. Often the complete code for an instruction can not be computed yet. For example, in line 94 the o set (or address) of input1 is not known until the code is linked. The assembler can compute the op-code for the mov instruction (which from the listing is A1), but it writes the o set in square brackets because the exact value can not be computed yet. In this case, a temporary o set of 0 is used because input1 is at the beginning of the part of the bss segment defined in this file. Remember this does not mean that it will be at the beginning of the final bss segment of the program. When the code is linked, the linker will insert the correct o set into the position. Other instructions, like line 96, do not reference any labels. Here the assembler can compute the complete machine code.

Big and Little Endian Representation

If one looks closely at line 95, something seems very strange about the o set in the square brackets of the machine code. The input2 label is at o set 4 (as defined in this file); however, the o set that appears in memory is not 00000004, but 04000000. Why? Di erent processors store multibyte integers in di erent orders in memory. There are two popular methods of

Endian is pronounced like storing integers: big endian and little endian. Big endian is the method indian.