Other than a smaller .data section, and reuse of names, is there any real advantage to using local stack variables instead of items in the .data section?

It seems like I'm always moving stuff from local to .data, when I later find that I need a variable that is in another proc. Why not just put everything in .data?

Are there any performance issues when using one method over the other?
Posted on 2001-08-11 14:04:34 by Newguy
Dealing with locals ususlly generates shorter instructions. PUSHing a local DD generates a 3 byte instruction, but a 6 byte instruction if PUSHing the same DD from data. But since they both take 2 clocks to run (.586) I don't think it makes much difference other than code size.

You do have the small ENTER/LEAVE overhead to clean up the stack when you use locals. :)
Posted on 2001-08-11 14:29:55 by S/390
The stack provides a flexiblity that you can't get from a data section with a static size. Stack locals are temporary where as global data is static and consumes memory - in a small program who cares (I have 512MB of ram). Recursion requires the flexiblity of a stack - I'm a big fan of recursion - all programs should be recursive. :) You could pass a local pointer to a sub-routine to return data that is local to that sub-routine, or modify local data. Usually, just thinking about the problem differently can provide a very flexible solution using local stack. Your code will be easier to reuse as an added side effect. IMHOPosted on 2001-08-11 14:59:53 by bitRAKE
A great advantage of using locals is when dealing with multitreading...
Posted on 2001-08-11 20:39:59 by f0dder

With a bit of practice, you will get used to the difference as both have their place. When you need a variable with GLOBAL scope, you place it in the .DATA or .DATA? section but if you need a variable only within the scope of a procedure, a LOCAL is the way to go.

The Intel data says that a LOCAL is usually accessed faster than a global because it is usually in the L1 cache at the start of the procedure but it also allows you to reuse names on a regular basis without having naming conflicts that will arise from a very large number of globals.


Posted on 2001-08-12 05:48:30 by hutch--
Global .Const, .Data and .Data? variables are quicker. About 4%. But local variables are more flexible and indipendant.
Posted on 2001-08-12 06:19:07 by sch.jnn
If however the data needs to be initialized, such as a WNDCLASS, you may get a smaller .exe by defining it in .data thus eliminating the initialization code e.g.

wc WNDCLASSEX <bla... blah>

Some times the code it takes to initialize a large struct (on the stack) is larger than the actual struct! It makes more sense to me in cases like this (where speed is not critical) to use the approach which results in smaller code.

Posted on 2001-08-12 06:22:46 by gfalen
Well, locals MAY be faster, but only if you optimize your code for the pentium, which is a lengthy task. If you would align all of your procedure's code on 8 bytes (a cache L1 page), you MAY get a noticable advantage. It's no fun to align the code though :)
Posted on 2001-08-12 06:24:34 by sch.jnn
Thanks for your comments. I guess I'll take Hutch's advice and play with both for a while.
Posted on 2001-08-12 14:14:43 by Newguy