This one I got from Jeff. Sharp criticism... The text written in italic is my original text, followed with the comment.
gcc (GNU C Compiler) is actually a collection of frontend tools that
Actually, gcc == GNU Compiler Collection - the whole family is
referred to as gcc.
Preprocessing: Producing code that no longer contains directives. Things like "#if" cannot be understood directly by the compiler, so this must be translated into real code. Macros are also expanded at this stage, making the resulting code larger than the original.
It also pulls in headers.
..manipulate them further. This work is done in multipass style, which demonstrates that it sometimes takes more than one scan through the source code to optimize.
It doesn't scan the source - it scans the intermediate format, which used to be RTL, but which is something else now.
...As you may already be aware, registers can be accessed hundreds or thousands times faster than RAM cells.
Exaggeration - Maybe ~100 cycles for going out to main memory, but these things will be in cache, so might cost a few cycles.
0x7530 is 30,000 in decimal form, so we can quickly guess the loop is..
0x7530 is hex, "0x7530 is 30,000 in hexadecimal form" or "0x7530 in decimal is 30,000"
simplified. This code represents the innermost loop and the outermost loop ("for(j=0;j<5000;j++) ... for(k=0;k<4;k++)") because that is literally a request to do 30,000 loops. Note that you just need to...</i>
5000 * 4 = 20000 loops.
Author's note: I admit this is solely my own mistake that confused number of loops with the current value of accumulator (
acc variable). The correct sentence should be "this code represents the middle and the innermost loop (
for(j=0;j<5000;j++) ...for(k=0;k<4;k++)</code>). In the end of these loops, accumulator is increased by 30,000".
To illustrate them better, here are the codes with inline comments. First check #1, then #2 and so on to understand the flow.
80483a6: jmp 80483c7 <main+0x37>
80483a8: add $0x7530,%ecx -> 4. acc += 30,000 ?
80483ae: cmp $0x11e1a300,%ecx 5. accumulator has reached 300,000,000 ?
80483b4: je 80483d0 <main+0x40>
80483b6: jmp 80483c7 <main+0x37>
80483b8: add $0x6,%edx --> 2. the innermost loop.
80483bb: add $0x1,%eax --> EAX is the counter for middle loop.
80483be: cmp $0x1388,%eax --> 3. have we loop 5,000 times yet?
80483c3: je 80483a8 <main+0x18>
80483c5: jmp 80483b8 <main+0x28>
80483c7: mov %ecx,%edx --> 1. starts here.
80483c9: mov $0x0,%eax
80483ce: jmp 80483b8 <main+0x28>
80483d0: mov %edx,0x4(%esp) -> 6. ready to print.
80483d4: movl $0x80484a0,(%esp)
80483db: call 80482b8 <printf@plt>
So, instead of originally looping 200,000,000 (10,000 * 5,000 * 4) times, it now does 50,000,000 (10,000 * 5,000) times only.
Now, on to parameter passing. In x86 architectures, parameters are pushed to the stack and later popped inside the function for further processing.
Sometimes popped, often they are left on the stack.
By using -mregparm, you basically break the Intel x86-compatible Application Binary Interface (ABI). Therefore, you should mention it when you distribute your software in binary only form.
Why? I see no problem shipping source with Makefiles that say
-mregparam. The ABI problem comes if you were to redeclare a library function as regparam and call it.