3 Machine-Level Representation of Programs

3.2  Program Encodings

• higher levels of optimization (e.g., specified with the option -O1 or -O2) are considered a better choice in terms of the resulting program performance.
• the C preprocessor expands the source code to include any files specified with #include commands and to expand any macros, specified with #define declarations. Second, the compiler generates assembly- code versions of the two source files having names p1.s and p2.s. Next, the assembler converts the assembly code into binary object-code files p1.o and p2.o.
• the linker merges these two object-code files along with code implementing library functions (e.g., printf) and generates the final executable code file p (as specified by the command-line directive -o p).

3.2.1 Machine-Level Code

• Being able to understand assembly code and how it relates to the original C code is a key step in understanding how computers execute programs.
• Whereas C provides a model in which objects of different data types can be declared and allocated in memory, machine code views the memory as simply a large byte-addressable array.
• the program memory is addressed using virtual addresses. At any given time, only limited subranges of virtual addresses are considered valid.
• the upper 16 bits must be set to zero, and so an address can potentially specify a byte over a range of 248, or 64 terabyte.

3.2.2 Code Examples

• To see the assembly code generated by the C compiler, we can use the -S option on the command line:
• linux> gcc -Og -S mstore.c
• If we use the -c command-line option, gcc will both compile and assemble the code
• linux> gcc -Og -c mstore.c
• To inspect the contents of machine-code files, a class of programs known as disassemblers can be invaluable. These programs generate a format similar to assembly code from the machine code. With Linux systems, the program objdump (for “object dump”) can serve this role given the -d command-line flag:
• linux> objdump -d mstore.o