3

When I compile the function below with: gcc -S teste.c

void readInput() {
    int buf;
}

teste.S becomes:

readInput:
     pushl   %ebp
     movl    %esp, %ebp
     subl    $16, %esp
     leave
     ret

my doubt is: why %esp is subtracted from 16 bytes, shouldn't it be 4 bytes for an int? Does it have todo with alignment?

Similar thing happen when I compile this:

void readInput() {
    char buf;
}

and the output is the same as above.

JohnTortugo
  • 6,356
  • 7
  • 36
  • 69
  • 1
    Please have a look at the following question : http://stackoverflow.com/questions/823138/understanding-empty-mains-translation-into-assembly – ScarletAmaranth Apr 16 '12 at 15:29

3 Answers3

0

The basic problem is that you're using no optimization, so it makes no effort to minimize the space it allocates or the code it generates. So what is going on here is that there's a bunch of stack space allocated for stuff that might be needed (unwind handlers, calls to setjmp/longjmp/alloca or other compiler builtin functions), but which isn't needed in your case as you never call the functions or use the features that might require them.

If you use optimization (even just -O1), this space will go away as the optimizer will see that its unused.

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
0

Cache Hit Rate

There are a few things going on.

  1. Compiling without optimization will leave artifacts of the code generator design around.
  2. Without further calls or -g, there is little need for a full stack frame.
  3. When space is allocated, and if the function is not a leaf node, it may make sense to allocate on cache line boundaries or on 1/2n subunits of one. The idea is that future calls may be in a loop, and if the new stack frames overlap two cache lines, or n + 1 cache lines, then they will waste space and reduce hit rate. Cache hit rate has been of critical importance for some time now. You can sometimes see modules and larger data structures over-aligned for the same reason. Of course, this conflicts with an also-reasonable goal of keeping stack usage small to, ahem, improve cache efficiency.
DigitalRoss
  • 143,651
  • 25
  • 248
  • 329
0

The stack is kept 16-byte aligned probably for SSE2. (which has 128-bit=16*8) registers. For 64-bit this is afaik mandatory even.

Strictly speaking for non SSE using leaf procedures this requirement could be omitted.

Marco van de Voort
  • 25,628
  • 5
  • 56
  • 89
  • How does subtracting 16 from `ESP` make it 16-byte aligned? – mtvec Apr 30 '12 at 15:32
  • If the stack is made n-byte aligned by the binary startup code (the files called crt*.o), and every change to the stack pointer is a multiple of n (bytes), the stack will remain n-byte aligned. – Marco van de Voort May 01 '12 at 10:03