This discussion of the stack frame, particularly regarding the graphics, describes 32-bit operations. In 32-bit mode, restrictions such as stack addressing are enforced strictly. While these restrictions are not enforced rigidly for 64-bit stack frame usage, their observance is probably still a good coding practice, especially if you count on reliable debugging information.

The compilers classify each routine into one of the following categories:

You must decide the routine category before determining the calling sequence.

To write a program with proper stack frame usage and debugging capabilities, use the following procedure:

The difference in stack frame usage for -n32 and -64 operations can be summarized as follows:

The portion of the argument structure beyond the initial eight doublewords is passed in memory on the stack, pointed to by the stack pointer at the time of call. The caller does not reserve space for the register arguments; the callee is responsible for reserving it if required (either adjacent to any caller-saved stack arguments if required, or elsewhere as appropriate). No requirement is placed on the callee either to allocate space and save the register parameters, or to save them in any particular place.

In most cases, high-level language routine and assembly routines communicate via simple variables: pointers, integers, booleans, and single- and double-precision real numbers. Describing the details of the various high-level data structures (arrays, records, sets, and so on) is beyond the scope of this book. If you need to access such a structure as an argument or as a shared global variable, refer to the MIPSpro N32/64 Compiling and Performance Tuning Guide.

The file begins with comments that indicate the name of the source file and the compiler that was used to produce the .s file. The options that were used by the compiler are also listed. It is often important to know the target machine that the instructions were intended for; this is discussed in the following subsections. By default, only a select set of options are included in the file. More detail can be obtained by including the -LIST:options flag on the compiler's command line.

One of the first pseudo-instructions in the file is similar to the following example:

     .section .text, 1, 0x00000006, 4, 64

or

     .section .text, 1, 0x00000006, 4, 16

This directive is used by the loader to align the start of the program's instructions at particular byte-address boundaries. The rightmost field is 16 if quad word alignment is required, or is 64 if cache line alignment is needed. The proper number is determined by the target processor type and the optimization level that was used because some optimizations require an exact knowledge of the I-Cache placement of each instruction while others do not benefit from this level of control.

A comment is attached to each label definition (recognized by the colon (:) following the name). This comment provides the byte offset of the label's location relative to the start of the .section .text directive. The first label, which usually corresponds to the first entry point of the first function, is 0x0.

The remaining labels have addresses that are increased by 4 bytes for each instruction that is placed between successive labels. These offsets are the same for both the .s file and the related .o files, although the loader can choose to place the start of the program (the 0x0 location) anywhere in the machine's address space. The start is subject only to the alignment restriction placed on the .section directive (see “Instruction Alignment”).

This is useful to note when you are using a debugger and trying to correlate the assembly file to the executed instructions. The machine addresses are sometimes difficult to translate to the file's relative offsets when only quad word alignment was requested.

The following is an example of this comment:

.BB1.kernel_:  # 0x0  

To help associate the compiler-generated code to the original source code, the line number and source code are inserted into comment lines that are interspersed with the assembly instructions. The comments usually appear ahead of the machine instructions that are generated for it. However, various optimizations may cause instructions to be moved or reordered and it is sometimes difficult to understand where they appear.

A further difficulty can arise if inline code expansion occurs. In these cases, the line number (503 in the following example) may refer to the line of the module that contained the inlined routine, and not to the original source code module of the compiled program. This can be especially confusing if the -ipa option was requested, and if several source code files were intermixed.

To determine the original file that contains a particular source code line, search for the immediately preceding .loc directive. This directive contains the line number and an index to a previous .file directive that identifies the file that the source code was read from. See Chapter 8, “Pseudo Op-Codes (Directives)” for information about the .loc directive.

The following is an example of this comment:

# 503              x[k] = q + y[k]*( r*z[k+10] + t*z[k+11] )

When any level of optimization greater than -O0 is requested on the command line, comments are added to the right of machine instructions that indicate the compiler's knowledge of the relative issue time for the particular instruction. These comments consist of an integer between square brackets, as shown in the following example:

     mul.d $f2,$f2,$f10              # [11]

In this example, the [11] indicates the clock cycle (relative to the start of the block) in which this instruction will be issued by the processor.

The assembly files targeted for processors that can only issue a single instruction in a clock period have unique times for each instruction in the block, while target processors that can issue multiple instructions may show that several instructions have the same integer in the issue time comment.

The times for processors that support Out-Of-Order issue of instructions may sometimes appear unusual because an instruction may be issued before other instructions that precede it in the block. This is common processor behavior. The compiler attempts to model the queuing mechanisms contained by the hardware and it uses knowledge of the details to arrive at meaningful times to place in these comment fields. The times are accurate to the limit that the machine is modeled.

Several simplifying assumptions are made to calculate these times, which make it difficult to estimate the performance of the code by using these comments alone. The most important point to make is that program flow is not taken into account. The actual performance of a program is influenced by the path taken into a particular block of code, which often determines when the inputs that an instruction needs will be ready. It would be difficult to model an entire program and take into account all possible paths into a block, so it is assumed that all inputs computed outside a block are available at the start of the block, and that all functional units are initially free to accept new operations.

Even with these restrictions, it is difficult to accurately model the behavior of load and store instructions. The compiler attempts to recognize accesses that will be satisfied from a data cache and use an appropriate latency. Although performance data suggests that most data references are to a cache, this can be very program-dependent. With the additional complexity introduced when multiple levels of cache are available, the compiler can never be certain that it is using the correct memory latency to produce the issue time comments. Because of these uncertainties, the compiler uses times that match what happens in the average program.

A limitation on the use of these times is illustrated with the following program example run on a machine with an R10000 processor:

.Lt.0.224:      # 0x508
        .loc    1 589 17  
# 589                  temp -= x[j]*y[j];
         ldc1 $f9,24024($3)              # [0]
         ldc1 $f10,32064($5)             # [1]
         addiu $2,$2,-1                  # [0]
         addiu $3,$3,8                   # [0]
         addiu $5,$5,8                   # [1]
         bne $2,$0,.Lt.0.224             # [1,1]
         nmsub.d $f4,$f4,$f9,$f10        # [4]

With just a glance at the times, you might conclude that a nmsub instruction will only be issued every 5 clock periods. However, as long as execution stays within the loop, the processor will prefetch instructions faster than it can execute them, resulting in an average issue of 1 nmsub instruction every 2 clock periods, limited by the 2 memory accesses that take 2 clock periods to issue.

There are occasions when the first instruction is not considered to be part of the block and no instruction issue time is computed for it. This happens when the block is frequently branched to using a label+4 address specification. The following example code illustrates this:

.Lt.0.274:      # 0x9ac
         or $3,$9,$0                     #
         or $6,$10,$0                    # [0]

The most frequent transfer to the label is the following instruction:

     bne $8,$30,.Lt.0.274+4                   # [0,1]  

If the target processor is an Out-Of-Order processor, the cycle when the hardware will predict the direction of a conditional branch is estimated. This happens at the time the instruction is first read into the instruction decode buffer and is independent of the time that the instruction actually issues.

This time is reported as the first of a pair of integers, in square brackets, in the comment field of the instruction. The second field is the issue time. In the preceding example, branch prediction happens in cycle 0, but the instruction will not issue until cycle 1 (because it has to wait for an input).

The compiler attempts to move inputs to conditional branches as far previously as possible so that both the branch prediction and the issue times are identical. However, there are conditions that prevent the compiler from doing so; this is done to minimize the number of instructions that are speculatively executed after the prediction and before the direction of the branch can be determined with certainty. It is only when the instruction completes execution that the hardware is certain which branch direction is correct.

If the wrong direction was predicted, all speculatively executed instructions will need to be aborted, wasting time that could have been devoted to completing the program.

A nop instruction is a real operation that does not change the contents of any registers. There are several that could be used, but the preferred one is sll $0,$0,0, which means “shift left by 0 bits the contents of register $0 and store the result into register $0”.

nop instructions usually waste space and should be deleted by the compiler, but there are situations where they are necessary for the correctness of the executed code and cases where they can improve the performance of the executed code. They are most often encountered as a placeholder for the delay slot of a branch instruction, when no other instruction can be found. The following code sequence illustrates this:

         addiu $5,$5,1                   # [0]
         bne $5,$30,.Lt.0.460            # [0,1]
         nop                             # [0]  

Other than their use in the delay slot of conditional branches, nop instructions are used to optimize the fetch and decode performance of processor types that can read, decode and execute multiple instructions in each clock period. These processors cannot group together instructions when a cache line boundary occurs between them, resulting in a delay that can be avoided by inserting one or more nop instructions ahead of a label.

The optimization that attempts this alignment depends on the processor type and the optimization levels selected. In the common case, the first block of each loop is forced to start on a quad word boundary. This is simple and fast although it sometimes causes nops to be added in the middle of a cache line, where they are not useful.

For the highest level of optimization, and only for Out-Of-Order issue processors, closer track is kept of cache line boundaries. This requires that the start of the module (that is, the address of the first text label) be aligned on a cache line boundary, increasing the size of the generated executable but allowing the compiler to avoid unnecessary instructions.

Along with optimally aligning instructions on Out-Of-Order processors, attention is paid to a timing "hiccup" that can occur if a branch instruction is separated from its delay slot instruction by a cache line break. The insertion of a nop before the branch can improve performance slightly. The following is an example of this. The nop forces the bne instruction to start in the next cache line, as can be determined by the address comment in the label field of the next block.

         nop                             # [1]
         bne $0,$1,.Lt.0.550             # [3,5]
         xori $1,$1,1                    # [5]
.BB307.kernel_: # 0x2408

Comments are added at the start of loops to indicate the transformations that were applied to the loop. The meanings of most of these are obvious, but some need some explanation:

A block is a sequence of instructions between 2 labels. Blocks are usually identified in the assembly file by a comment between the starting label and the first instruction with a comment that contains BB:xxx. The block number that follows the BB: is used to identify each unique block of the program. Comments that start with <freq> BB:xxx frequency = yyy.yy indicate how often the compiler believes the block is executed for each invocation of the function where the block is located.

The comment is followed by (heuristic) or (feedback) to indicate how that average was arrived at. Because many optimizations utilize this information, incorrect information can result in sub-optimal compiler output. It is important that the feedback data be generated by tests that truly represent the expected behavior of the final program so that accurate decisions can be made by the compiler.

Blocks that end with conditional branches also contain comments similar to <freq> BB:xxx => BB:yyy probability = 0.zzzzz. These indicate the compiler's estimation for the direction of each possible branch. Again, it is important for optimal performance that feedback be generated by test cases that are representative of the actual workload.