tags:

views:

189

answers:

5

What is the difference when the compiler allocates variables on the stack in x86 v x64 architectures? Say I have a function

foo(){
    int i = 5;
    i += 4;
}

how is this allocated on the stack differently in these two architectures?

+1  A: 

Perhaps I haven't worked enough with 64bit CPUs [most of my assembly programming is in MIPS; a little x86], but why should there be a difference?

Did you try it? Look at what instructions are produced...

Mikeage
+1  A: 

Well, for starters all the saved registers (EIP, ESP, etc.) will be 64bit long. This means that in your example the 'int' will be 64bits. But as far as I know, the stack has the same format, albeit with different sizes.

terminus
+1  A: 

The compiler is much less likely to even put this variable on the stack at all - it will most likely keep this variable in a register. The differences are on whether the compiler has to store info on the stack, moreso than how it stores it.

Paul Betts
in fairnss i suspect the comiler wil completely optimise that out due to it not doing anything...
Goz
But that doesn't change between 64-bit and 32-bit compilers. The example in the question is just that, an example. I would assume that `i` is something that will be used a few times down the line and won't be compiled away.
Nathan Fellman
+1  A: 

As Paul notes, the compiler probably won't put this variable on the stack at all. I just wanted to mention that the idea of the compiler running out of registers and finally using the stack for variable storage is called "register spilling", and you can read more about it on Wikipedia.

Conrad Meyer
+2  A: 

For Microsoft's x64 ABI, have a look at http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx under "Stack Usage". It is considerably different from their x86 ABI.

Other x64 ABIs (Linux, OS X, etc) are probably similar but subtly different from Microsoft's. GCC's documentation would probably be a good place to start looking for those.

Vadim K.