hurry wrote:
In order to avoid declaring static variables in a function I was asked
to write a scratch memory.
Reserve a block of memory outside the function and assigning pointers
to the memory locations as per convenience and access them.
I was told this would save some memory. I dont understand the logic
behind this, as i`ve declared variables as global (assuming i`ve
declared the block in main() ) this would always b a residual data for
access at any point of the prog. against static var. which wud b
available for access only whn it enters the function.

If anyone has ever written a scratch memory pls confirm if my
understanding is right and its use too.

All of a program's static objects (whether inside
or outside of functions) exist and occupy their memory
for the entire duration of the program. If the program
doesn't actually need all of them simultaneously, that
might amount to a waste of memory. For example, imagine
a program that proceeds in "phases:" it initializes, it
does the first, second, parts of its calculation,
then it writes its results, cleans up, and terminates.
If there are functions that are used only in Phase N and
not in any earlier or later phases, the memory their
static variables occupy is wasted except while Phase N is
actually running.

However, using dynamically-allocated memory has plenty
of pitfalls and offers many chances for you to gain practice
with the debugger Before embarking on some kind of
wholesale replacement of static with dynamic memory, you
should assess just how much waste there actually is, whether
that's important in the Grand Scheme of Things. Changing
your car's motor oil regularly can help your gas mileage,
but changing it every day is a false economy.

also any link to understand on how memory is handled during a
c-program`s (on windows) execution would b of hlp.

Each data object in C has a "storage duration," or loosely
speaking a "lifetime." There are three such:
- Static storage duration: The data object exists and
occupies memory for the entire execution of the program,
as described above. Static storage should, IMH, be
used sparingly, especially static storage with external
linkage ("global variables").
- Automatic storage duration: The data object "belongs"
to a block of executable code (a function, or a sub-
block within a function). The object's lifetime is
tied to the execution of the block: while the block
is active, the object exists and occupies memory, but
when execution leaves the block the object disappears
and its memory becomes available for other objects to
occupy. If a block is entered recursively, a whole
new set of block-local objects is created, occupying
memory that is distinct from that of the outer blocks.
- Dynamic storage duration: You control the lifetime of
the object explicitly, granting it memory and rescinding
the grant whenever you choose. You use malloc() or
calloc() or realloc() to allocate the memory, and free()
or realloc() to release it. This is the most flexible
method, and also the most error-prone.

Specific implementations of C may take liberties with the
schemes outlined above, so long as a conforming program cannot
tell that they've cheated. For example, an implementation
might decide to allocate memory for an auto variable before
its block is entered, and retain the memory for some time
after execution leaves the block:

void func(void) {
{
/* subordinate block 1 */
int inner1 = 42;

}
{
/* subordinate block 2 */
double inner2 = 42.0;

}
}

Some implementations might allocate memory for both inner1
and inner2 as soon a func() is called, without waiting for
their subordinate blocks to be entered. Such implementations
are also likely to keep that memory around until func() returns,
even though (in principle) inner1 and inner2 cease to exist
when their blocks end. Such shenanigans are permitted in the
name of efficiency, but are not to be relied upon -- for
example, this would be an error:

void func(void) {
int *ptr;
{
/* subordinate block */
int inner = 42;
ptr = &inner;

}
printf ("%d\n", *ptr); /* WRNG! */
}

because when the subordinate block finishes, the memory
allocated to inner may (in principle, "does") disappear, so
ptr finds itself pointing at something that no longer exists.

To find out whether the compiler you happen to be using
does this sort of thing, and under what circumstances, consult
its documentation. But the wiser course may be to remain
intentionally ignorant, lest you start confusing what your
current compiler happens to do with what the C languages
promises it will do. Upgrade to a newer version of the compiler,
and all the non-promised behaviors are subject to change.

In article <1139483702.024850.167300@z14g2000cwz.googlegroups. com>,
hurry <hurrynarain@gmail.comwrote:
In order to avoid declaring static variables in a function I was asked
>to write a scratch memory.
>Reserve a block of memory outside the function and assigning pointers
>to the memory locations as per convenience and access them.
>I was told this would save some memory. I dont understand the logic
>behind this, as i`ve declared variables as global (assuming i`ve
>declared the block in main() ) this would always b a residual data for
>access at any point of the prog. against static var. which wud b
>available for access only whn it enters the function.

Whether the data is accessible or not, if it is declared static
then it will continue to exist while other functions are running.
Using static variables in functions is therefor not a method of
saving space, other than to the extent that using a static variable
might allow you to avoid passing the reference to the memory
down through a number of calling layers.

If I understand what you have written correctly, whoever made this
request of you is dealing with a different matter, which is that
if you have static memory being allocated in a number of different
functions, the static memory does not necessarily all need to exist
at the same time. The other poster referred to "phases": you might
need a variable set to be alive for the first part of a program,
but then it might no longer be needed but a different variable set
might be needed. If you are using "scratch memory" of the form you
describe above, then after the end of the first phase, you can
reuse the block of static memory for the second purpose, without
having to allocate more memory. The total amount of memory required
then becomes the maximum of the sums of the sizes of the static variables
that must simultaneously exist at various points, rather than the
sums of the sizes of the sizes of the static variables that might exist
at some point in program execution.

Along the same lines: sometimes static memory exists for convenience
to prevent having to recalculate values. While you are in a section
of code that needs the calculated values repeatedly, you hold on to
the static memory, but there then might be a noticable time gap before
you need the values again. If the recalculation of the values is less
"expensive" than the cost of memory to hold on to them for that time,
then it might make sense to flush them, re-use the memory for something
else, and then recalculate them later.

Random example: if you are programming a game for a cell phone, then
before the game itself starts, you might be scrolling the list of
high scores repeatedly until the user triggers a start. The displayable
version of the scores is likely not exactly the same as the internal
representation, especially if the scores are held in a slow-access
low-power memory rather than in higher-current fast RAM. So you might
put the displayble scores into memory of static duration. And once
the user starts the game, you don't need that memory anymore, not
until the user finishes the game and it is time to display the new
high-score list. It would be a waste to hold on to that static memory
all through the game, when the cost of recalculating it is not high.

In article <1139521359.655919.249210@g43g2000cwa.googlegroups. com>,
dave windsor <nullcore@gmail.comwrote:
[quoting me]

>Whether the data is accessible or not, if it is declared static
>then it will continue to exist while other functions are running.
>Using static variables in functions is therefor not a method of
>saving space, other than to the extent that using a static variable
>might allow you to avoid passing the reference to the memory
>down through a number of calling layers.

>I am not sure what you mean by this. Static variables declared inside
>of functions still remain scoped within this function; the static
>keyword applied to otherwise automatic variables does not change the
>scope of that variable. Maybe I'm not understanding what you mean?

If you have a data structure that you need to persist between calls,
then you need a handle to it.

If you use a static variable that is scoped within the utilizing
function, then the handle is already right there and known to the
compiler, and no space needs to be allocated to keeping track of the
object.

If, though, you do not use static but the object must persist, then you
have to pass the object address around on the call stacks, possibly
through numerous layers, so that you can get ahold of the object
again. This passing around on call stacks usually uses space,
sometimes two pointers' worth per object per level [e.g., if the code
can't figure out that you aren't modifying the passed value because of
pointer aliasing concerns, then the code might decide to take a copy
instead of just passing down the original.] So in this case, using a
static can save on overall memory use.

The wording of the original poster could be read as suggesting that the
original poster was unaware that static'd memory continues to hang
around, that the poster thought that it -somehow- dropped out of the
memory usage requirements while variable is not in scope, only to
-somehow- be returned to life when static variable returns to scope.

10 Feb 2006 01:38:34 -0800, in comp.lang.c , "hurry"
<hurrynarain@gmail.comwrote:

>I understand var. which are casted as static are var. which are
>intended to occupy memory through out the progr. but, what I was not
>sure of was, if declared in main memory would it not always be
>available for access in other words, it would reside in fast memory (
>If I am using the term correctly )

C has no concept of "main memory" or "fast memory". What C /does/ have
is differing durations and differing scopes.

"scope" comes in two flavours of interest, file-scope, which most
people think of as global, and block-scope. The latter refers to
variables declared inside functions or inside blocks inside functions,
ie somewhere between a { and a }.

"duration" also comes in flavours. Static duration objects exist for
the entire duration of your programme. Automatic duration objects
exist only as long as they're in scope.

>In such a scenario does it make sense to declare a memory in global or
>am i missing something.

I have no idea what problem you're trying to solve, but if it has
something to do with keeping a variable in "fast" memory then C can't
answer you.
Mark McIntyre

Mark McIntyre wrote:

10 Feb 2006 01:38:34 -0800, in comp.lang.c , "hurry"
<hurrynarain@gmail.comwrote:
>
>I understand var. which are casted as static are var. which are
>intended to occupy memory through out the progr. but, what I was not
>sure of was, if declared in main memory would it not always be
>available for access in other words, it would reside in fast memory (
>If I am using the term correctly )
>
C has no concept of "main memory" or "fast memory". What C /does/ have
is differing durations and differing scopes.

"scope" comes in two flavours of interest, file-scope, which most
people think of as global, and block-scope. The latter refers to
variables declared inside functions or inside blocks inside functions,
ie somewhere between a { and a }.

Parameters in function prototypes have function prototype scope,
and parameters in old style function definitions
have function scope.

hurry wrote:

In order to avoid declaring static variables in a function I was
asked
to write a scratch memory.
Reserve a block of memory outside the function and assigning pointers
to the memory locations as per convenience and access them.
I was told this would save some memory. I dont understand the logic
behind this, as i`ve declared variables as global (assuming i`ve
declared the block in main() ) this would always b a residual data for
access at any point of the prog. against static var. which wud b
available for access only whn it enters the function.

If anyone has ever written a scratch memory pls confirm if my
understanding is right and its use too.

A bit late to the party, but let me try:

Are you perchance looking to simulate malloc()/free() without actually
doing them? What I understand you're looking for is a global (file
scope) array which plays the part of the dynamic memory pool. You dip
into it without needing to call malloc() with it's possible overheads.
You'd probably create it as an array of chars, and access data
through /very/ carefully cast pointers.

<T>
If you can control physical storage, you can tell linker to put this
array in the fastest chunk of memory on your system (e.g. super-fast
internal SRAM of your DSP).
</T>

You'd still need to do book-keeping though, as you'd have to know
whether there's any space left in your pool. Essentially, you'd need
your own home-grown malloc() and free(). Whether these will be faster
than the garden variety ones depends on your circumstances.

<T>
Did you try just telling your linker to put heap into your super-fast
memory? You could then use standard functions.
</T>

Jordan Abel wrote:
2006-02-11, pete <pfiland@mindspring.comwrote:
>
>>Mark McIntyre wrote:
<snip>
C has no concept of "main memory" or "fast memory". What C /does/ have
is differing durations and differing scopes.

"scope" comes in two flavours of interest, file-scope, which most
people think of as global, and block-scope. The latter refers to
variables declared inside functions or inside blocks inside functions,
ie somewhere between a { and a }.
>>
>>Parameters in function prototypes have function prototype scope,
>>and parameters in old style function definitions
>>have function scope.
>
What scope do parameters in function prototypes that are part of a [new
style] function definition have?

Block scope.

"function prototype scope" appears at
first glance to mean that they're not in scope in the function body.

Yep.

C99, 6.2.1#4

"[] If the declarator or type specifier that declares
the identifier appears inside a block or within the list
of parameter declarations in a function definition, the
identifier has block scope, which terminates at the end
of the associated block. If the declarator or type
specifier that declares the identifier appears within
the list of parameter declarations in a function
prototype (not part of a function definition), the
identifier has function prototype scope, which
terminates at the end of the function declarator. []"

Cheers
Michael