This question comes from answering Stack Overflow question Why do books say, “the compiler allocates space for variables in memory”?, where I tried to demonstrate to the OP what happens when you allocate a variable on the stack and how the compiler generates code that knows the size of memory to allocate. Apparently the compiler allocates much more space than what is needed.
However, when compiling the following
#include <iostream>
using namespace std;
int main()
{
int foo;
return 0;
}
You get the following assembler output with Visual C++ 2012 compiled in debug mode with no optimisations on:
int main()
{
00A31CC0 push ebp
00A31CC1 mov ebp,esp
00A31CC3 sub esp,0CCh // Allocates 204 bytes here.
00A31CC9 push ebx
00A31CCA push esi
00A31CCB push edi
00A31CCC lea edi,[ebp-0CCh]
00A31CD2 mov ecx,33h
00A31CD7 mov eax,0CCCCCCCCh
00A31CDC rep stos dword ptr es:[edi]
int foo;
return 0;
00A31CDE xor eax,eax
}
Adding one more int
to my program makes the commented line above to the following:
00B81CC3 sub esp,0D8h // Allocate 216 bytes
The question raised by @JamesKanze in my answer linked atop, is why the compiler, and apparently it's not only Visual C++ (I haven't done the experiment with another compiler), allocated 204 and 216 bytes respectively, where in the first case it only needs four and in the second it needs only eight?
This program creates a 32-bit executable.
From a technical perspective, why may it need to allocate 204 bytes instead of just 4?
EDIT:
Calling two functions and creating a double
and two int
in main, you get
01374493 sub esp,0E8h // 232 bytes
For the same program as the edit above, it does this in release mode (no optimizations):
sub esp, 8 // Two ints
movsd QWORD PTR [esp], xmm0 // I suspect this is where my `double` goes
See Question&Answers more detail:os