Date: Sun, 14 Jun 1998 14:11:04 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Matthew Conte <spam AT somebody DOT else>
cc: djgpp AT delorie DOT com
Subject: Re: 64k demo (slightly off-topic reply)
In-Reply-To: <6lvpq2$4e@sjx-ixn4.ix.netcom.com>
Message-ID: <Pine.SUN.3.91.980614140620.6294a-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Sun, 14 Jun 1998, Matthew Conte wrote:

> Here was my logic: static variables/arrays can only be accessed by the
> source file that they are declared in, so I figured that they would be
> closer to the functions they were used in on the stack.  A global
> variable/array can be accessed by any source file/function that uses it, so
> accesses to it are further along on the stack, and this access takes longer.
[snip] 
> Is there a flaw in my logic?

There's a lot of flaws in the above ;-).

First, data (variables) and code (functions) are in two different 
segments, and so being ``close'' to one another has no meaning here (they 
can be physically apart).

Second, global and static variables are NOT on the stack at all.  Only 
automatic variables (those declared inside a function and without the 
static qualifier) are on the stack.

Finally, the speed of accessing a variable does not depend at all on how 
``far'' or ``close'' it is to the current stack frame.  Like Nate said, 
memory is memory is memory.