If I understand what MSVC2010 does (which might NOT be the case) it looks that variable isn't in the stack.
When I see:
mov dword ptr [somevar],someconstantvalue
My understanding is it's implicitly pointing at the data segment, not the stack segment.
Why do you think that can't be on the stack? o.O
edit: all that's saying is that it's moving the value someconstantvalue of the size of a dword ptr into the location somevar iirc.
Not exactly. I'm sorry if there's some confusion, probably there's also a problem with my awful english but from my pov that variable isn't on the stack, strctly speaking.
That instruction not olnly says it's a copy operation, it also implies the target location is in the data segment. Actually it's equivalent to:
mov dword prt ds:[somevar], someconstantvalue
If it was in the stack segment it would have been:
mov dword prt ss:[somevar], someconstantvalue
because copying to ss,es and fs *requires* the segment to be specified.
In this specific case registers+segments inspection shows the stack segment is also the data segment but I strongly doubt this is a normal situation for any non trivial application.
So we are both right. The variable lies in the stack because the stack is also the data segment, but the variable is used as a common variable declared in a data segment.
Another proof the variable is handled as if it was a common variable is there are no push/pop ops inside the while loop.
And this level of optimization surprises me a lot because I also expected to see secondVariable be handled like it was nothing but a value in the stack.
Actually when I add a function inside the while loop I get the expected push/pop operations before/after the function call and movs positioning/resetting the base pointer (bp) relative to the stack pointer (sp). Which is exactly what I expected to see in the first place instead of a mov targetting the data segment!
As for me, I'm definitely impressed by how MSVC 2010 is handling this (very trivial) exe!