Compiling with optimization

You might be wondering why the particular compiler we used to generate our little object program created so much code for a program that basically didn't do anything. Good question. Remember that each compiler you encounter may generate slightly different assembly language code; however, your program will still generate the results you require of it. If we compile using optimization, we get a very different set of assembly instructions. For that matter, if we were to compile the program using a different compiler altogether, we can expect to see different assembly code again.

Let's take a quick peek at the same program compiled with optimization. The output has been trimmed , as displaying 10 hex (16 decimal) instructions was more than enough.

Figure 18-4 Little's assembly code after compilation with optimization

 Hiya...  cc -o little -O little.c  Hiya...  adb little -   main,10?ai  main:         main:           mov     0x1, %o0  main+4:               mov     0x2, %o1  main+8:               mov     0x3, %o2  main+0xc:     mov     %o7, %g1  main+0x10:    call    fred  main+0x14:    mov     %g1, %o7  main+0x18:    unimp   0x0  main+0x1c:    unimp   0x0  main+0x20:    unimp   0x0  main+0x24:    unimp   0x0  fred:         jmp     %o7 + 0x8  fred+4:               nop 

From this we see that the compiler was clever enough to not even bother with generating assembly code to create new stack frames for main() and fred() . The compiler, however, did generate code to prepare the calling arguments and to call fred() as our original C code requested . So, in effect, this optimized code is still a perfectly valid representation of our program. In fact, it's even closer to the original source: fred() 's code consists of a jump back to where it came from.