TABLE OF CONTENTS One of the most important skills involved in optimizing Itanium processor code is the ability to read compiler-generated assembly language output files to see what is really going on under the hood. What may look like perfectly reasonable high-level code on the surface may translate to something quite unexpected, and possibly slower than expected, under the surface.
The assembly language listings that compilers output often look confusing, and it is easy to get disoriented without the high-level source code as a guide. Often, the only recognizable terms are the names of global procedures and variables. Consider the case of the small C language module, containing just one function, shown in Figure 11.1.
intchecksum(int *where, int count){ int sum; sum = 0; while (count--) { sum += *where++; } return sum;} |
By using the /S option, the compiler can be told to generate an assembly language file representing the way it actually translates the C code into assembly language.
ecl /S checksum.c
The resulting file, checksum.asm, has the asm file type suffix by default.
The assembly language file so produced has 128 lines of code, but most of that consists of standard startup declarations that can be skipped over. The core assembly code for this simple function is shown in Figure...
