scratch memory

[hurry]

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.

----

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

bye,
hurry.

[Eric Sosman]

Re: scratch memory

hurry wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> also any link to understand on how memory is handled during a
> c-program`s (on windows) execution would b of hlp.[/color]

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, IMHO, 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); /* WRONG! */
}

.... 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.

--
Eric Sosman
esosman@acm-dot-org.invalid

[Walter Roberson]

Re: scratch memory

In article <1139483702.024 850.167300@z14g 2000cwz.googleg roups.com>,
hurry <hurrynarain@gm ail.com> wrote:[color=blue]
> 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.[/color]

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.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

[dave windsor]

Re: scratch memory

Good responses to this question. "Scratch memory" is more commonly
used in applications that is run on embedded architectures, where
memory requirements are a major concern. In environments lacking a
MMU, managing one's own memory becomes necessary. These situations do
not lend themselves well to using static variables, which remain in
memory persistently. An environnment that supports demand
paging/virtual memory would optimize memory usage transparently,
allowing for liberal use of statics. Since this is not possible in
many embedded devices, the job is left to the programmer.
[color=blue]
>
> 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.
>[/color]

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?

[Walter Roberson]

Re: scratch memory

In article <1139521359.655 919.249210@g43g 2000cwa.googleg roups.com>,
dave windsor <nullcore@gmail .com> wrote:
[quoting me]
[color=blue][color=green]
>> 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.[/color][/color]
[color=blue]
>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?[/color]

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.
--
All is vanity. -- Ecclesiastes

[dave windsor]

Re: scratch memory

[color=blue]
>
> 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.[/color]

Ahh, I didn't realize you were referring to the actual stack memory
allocated for holding the handle.
[color=blue]
> 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.[/color]

Although you are right about space being saved in the stack frame, I do
not think that this is a good use of the static keyword. The space
saved here is some multiple of sizeof() a pointer, which is
architecture dependent, but will usually be less than that of the
actual data structure which is being unnecessarily kept in memory. The
effects of this are compounded as the data structure remains in memory
over time, as the space being occupied by the data structure could be
used for objects which are actually being referenced.

[hurry]

Re: scratch memory

Thnx for those who had contributed to the thread.

[quotin myself]
--------------------------------------------

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.
-------------------------------------------

[quoting Roberson]
---------------------------------------------
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.
-------------------------------------------


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 ) (i.e for a quick fetch) and the
prog. does not have "different values or variables requirement at diff
phases" problem.
Its the same variables which are reqd. and with the same values from
the prev. execution.

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

[Mark McIntyre]

Re: scratch memory

On 10 Feb 2006 01:38:34 -0800, in comp.lang.c , "hurry"
<hurrynarain@gm ail.com> wrote:
[color=blue]
>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 )[/color]

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.
[color=blue]
>In such a scenario does it make sense to declare a memory in global or
>am i missing something.[/color]

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
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[pete]

Re: scratch memory

Mark McIntyre wrote:[color=blue]
>
> On 10 Feb 2006 01:38:34 -0800, in comp.lang.c , "hurry"
> <hurrynarain@gm ail.com> wrote:
>[color=green]
> >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 )[/color]
>
> 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 }.[/color]

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

--
pete

[Vladimir S. Oka]

Re: scratch memory

hurry wrote:
[color=blue]
> 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.[/color]

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.

<OT>
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).
</OT>

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.

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

--
BR, Vladimir

We don't smoke and we don't chew, and we don't go with girls that do.
-- Walter Summers

[dave windsor]

Re: scratch memory

> I understand var. which are casted as static are var. which are[color=blue]
> 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 ) (i.e for a quick fetch) and the
> prog. does not have "different values or variables requirement at diff
> phases" problem.
> Its the same variables which are reqd. and with the same values from
> the prev. execution.
>[/color]

Not really sure what you're saying here...
For an instruction to execute, the instruction itself as well as the
data needed by the instruction need to be in main memory. On most
systems you'll use, the CPU handles this transparently; there is no
need to explicitly "place" things in memory programatically in C.

There is such thing as "fast memory," however, in the form of cache
memory. However, the contents of CPU cache cannot be explicitly
controlled using ANSI C, and also because the CPU cache is totally out
of the scope of a language such as C. "Frequently accessed things,"
such as the stack, end up cached.

In your case, a global variable is not necessarily going to be cached
simply because it is global. If this variable is frequently used in
your program, it's memory address and contents are more likely to
remain in cache.

[Jordan Abel]

Re: scratch memory

On 2006-02-11, Mark McIntyre <markmcintyre@s pamcop.net> wrote:[color=blue]
> On 10 Feb 2006 01:38:34 -0800, in comp.lang.c , "huasdrry"
> <hurrynarain@gm ail.com> wrote:
>[color=green]
>>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 )[/color]
>
> C has no concept of "main memory" or "fast memory".[/color]

*cough* Except for the register keyword. Note, however, that "The extent
to which such suggestions are effective is implementation-defined."

(There is also, of course, the issue that disk files can be considered a
type of "memory")
[color=blue]
> 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.[/color]

C provides an answer - It may not be one that is universally applicable,
but it does provide one
[color=blue]
> Mark McIntyre[/color]

[Jordan Abel]

Re: scratch memory

On 2006-02-11, pete <pfiland@mindsp ring.com> wrote:[color=blue]
> Mark McIntyre wrote:[color=green]
>>
>> On 10 Feb 2006 01:38:34 -0800, in comp.lang.c , "hurry"
>> <hurrynarain@gm ail.com> wrote:
>>[color=darkred]
>> >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 )[/color]
>>
>> 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 }.[/color]
>
> Parameters in function prototypes have function prototype scope,
> and parameters in old style function definitions
> have function scope.[/color]

What scope do parameters in function prototypes that are part of a [new
style] function definition have? "function prototype scope" appears at
first glance to mean that they're not in scope in the function body.

[Michael Mair]

Re: scratch memory

Jordan Abel wrote:[color=blue]
> On 2006-02-11, pete <pfiland@mindsp ring.com> wrote:
>[color=green]
>>Mark McIntyre wrote:[/color][/color]
<snip>[color=blue][color=green][color=darkred]
>>>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 }.[/color]
>>
>>Parameters in function prototypes have function prototype scope,
>>and parameters in old style function definitions
>>have function scope.[/color]
>
> What scope do parameters in function prototypes that are part of a [new
> style] function definition have?[/color]

Block scope.
[color=blue]
> "function prototype scope" appears at
> first glance to mean that they're not in scope in the function body.[/color]

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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.