memory use

[Michael]

In the below example, I beleive that the char array buffer[40] should
only occupy 40 bytes of the stack within the inner braces.

However the compiler seems to use 40 bytes of the stack througout the
entire function that this example is cut from. Is this normal?

if(midnightflag==1)
{
lcd_clear();
lcd_locate(1,1);
lcd_display("Updating date");
{ unsigned char buffer[40];
daydateyear(buffer);
senduart2(buffer);
senduart2("\r\n");
};
update_date();
midnightflag=0;
};

 

[Jim]

In the below example, I beleive that the char array buffer[40] should
only occupy 40 bytes of the stack within the inner braces.

However the compiler seems to use 40 bytes of the stack througout the
entire function that this example is cut from. Is this normal?

if(midnightflag==1)
{
lcd_clear();
lcd_locate(1,1);
lcd_display("Updating date");
{ unsigned char buffer[40];
daydateyear(buffer);
senduart2(buffer);
senduart2("\r\n");
};
update_date();
midnightflag=0;
};

The compiler is not even obliged to use a stack!

Jim

 

[Gordon Burditt]

In the below example, I beleive that the char array buffer[40] should

only occupy 40 bytes of the stack within the inner braces.

(1) what stack?
(2) which stack?

Standard C is not required to use a stack.

However the compiler seems to use 40 bytes of the stack througout the
entire function that this example is cut from. Is this normal?

How did you determine this from the code below, or, for that
matter, using any portable code?
And what difference does it make?

if(midnightflag==1)
{
lcd_clear();
lcd_locate(1,1);
lcd_display("Updating date");
{ unsigned char buffer[40];
daydateyear(buffer);
senduart2(buffer);
senduart2("\r\n");
};
update_date();
midnightflag=0;
};

Gordon L. Burditt

 

[Malcolm]

In the below example, I beleive that the char array buffer[40] should
only occupy 40 bytes of the stack within the inner braces.

However the compiler seems to use 40 bytes of the stack througout the
entire function that this example is cut from. Is this normal?

Yes. A compiler can implement automatic variables in any way it likes. Some
small embedded systems don't even use a stack but allocate to fixed areas of
memory.
However typically a compiler will adjust the stack frame on function entry
to hold all variables declared in that function, and reset it on function
exit. This means that your block scope array is treated as if it had
function scope. Your own system may be different, but probably not if it is
a major compiler.

 

[Keith Thompson]

In the below example, I beleive that the char array buffer[40] should
only occupy 40 bytes of the stack within the inner braces.

However the compiler seems to use 40 bytes of the stack througout the
entire function that this example is cut from. Is this normal?

Yes. A compiler can implement automatic variables in any way it likes. Some
small embedded systems don't even use a stack but allocate to fixed areas of
memory.

Note that an implementation that doesn't support recursion (and
therefore distinct storage for local variables for each function call)
is not conforming, though it might still be useful.

On the other hand, using a fixed area of memory for a function that's
known not to be called recursively is perfectly legal.

 

[Peter Nilsson]

(e-mail address removed) (Michael) wrote...

In the below example, I beleive that the char array buffer[40] should
only occupy 40 bytes of the stack within the inner braces.

As far as the language specification is concerned automatic data will
only be allocated at the point of declaration, and will expire at the
end of the enclosing block scope.

However the compiler seems to use 40 bytes of the stack througout the
entire function that this example is cut from. Is this normal?

if(midnightflag==1)
{
lcd_clear();
lcd_locate(1,1);
lcd_display("Updating date");
{ unsigned char buffer[40];
daydateyear(buffer);
senduart2(buffer);
senduart2("\r\n");
};
update_date();
midnightflag=0;
};

An implementation can do whatever it likes, so long as it preserves
the semantics of strictly conforming code.

If silently moving the declaration of buffer to the top of the
function block would not change the semantics of your code, then your
compiler can (and likely will) do so in the interests of runtime
efficiency.

But comp.lang.c is not the forum to discus what particular
implementations do under the hood, unless it's to gain an
understanding of C language itself. [Understanding C in terms of
assembler or debugging/profiling tools is not something that clc
encourages, nor should it.]

 

[Old Wolf]

In the below example, I beleive that the char array buffer[40] should
only occupy 40 bytes of the stack within the inner braces.

However the compiler seems to use 40 bytes of the stack througout the
entire function that this example is cut from. Is this normal?

if(midnightflag==1)
{
{ unsigned char buffer[40];
};
};

The braces dictate that the name "buffer" is available only
within those braces. However the actual 40 bytes can exist at
any time. The compiler could even allocate them at compile-time
if it determined that the function was never called re-entrantly
(I know of a compiler that does this).

 

[Michael]

In the below example, I believe that the char array buffer[40] should
only occupy 40 bytes of the stack within the inner braces.

(1) what stack?

The stack in an MSP430 microcontroller

(2) which stack?

The MSP only has one.

Standard C is not required to use a stack.


How did you determine this from the code below, or, for that
matter, using any portable code?

By viewing the assembly code generated by the compiler.

And what difference does it make?

The imagecraft compiler I am using allocates memory for static and
global variables in the lower part of memory, it then uses the stack
for other variables from the top of memory downwards.

I wish to increase the size of a static array as much as possible
without the stack overwriting it. I placed breakpoints in parts of my
program where i had a lot of variables in scope, to see how low the
stack pointer was.

Sorry my question wasn't very clear, what I wanted to know was:

In the code below (whether using a stack or not), should the char
array buffer[] occupy memory for the entire function which this code
is cut from (even though it is only accessible within the braces), OR,
should it only occupy memory within the braces. I would have thought
the latter, but maybe this is not a requirement of standard C.

if(midnightflag==1)
{
lcd_clear();
lcd_locate(1,1);
lcd_display("Updating date");
{ unsigned char buffer[40];
daydateyear(buffer);
senduart2(buffer);
senduart2("\r\n");
};
update_date();
midnightflag=0;
};

Gordon L. Burditt

 

[Michael]

In the below example, I beleive that the char array buffer[40] should
only occupy 40 bytes of the stack within the inner braces.

However the compiler seems to use 40 bytes of the stack througout the
entire function that this example is cut from. Is this normal?

Yes. A compiler can implement automatic variables in any way it likes. Some
small embedded systems don't even use a stack but allocate to fixed areas of
memory.
However typically a compiler will adjust the stack frame on function entry
to hold all variables declared in that function, and reset it on function
exit. This means that your block scope array is treated as if it had
function scope. Your own system may be different, but probably not if it is
a major compiler.

Thanks Malcolm.

 

[Robert Harris]

[snip]

Sorry my question wasn't very clear, what I wanted to know was:

In the code below (whether using a stack or not), should the char
array buffer[] occupy memory for the entire function which this code
is cut from (even though it is only accessible within the braces), OR,
should it only occupy memory within the braces. I would have thought
the latter, but maybe this is not a requirement of standard C.

Definitely the latter (see section 6.2.4 of the standard). The former
behaviour is often achieved with the alloca() function.

Robert

if(midnightflag==1)
{
lcd_clear();
lcd_locate(1,1);
lcd_display("Updating date");
{ unsigned char buffer[40];
daydateyear(buffer);
senduart2(buffer);
senduart2("\r\n");
};
update_date();
midnightflag=0;
};

Gordon L. Burditt

 

[Keith Thompson]

[snip]
Sorry my question wasn't very clear, what I wanted to know was:
In the code below (whether using a stack or not), should the char
array buffer[] occupy memory for the entire function which this code
is cut from (even though it is only accessible within the braces), OR,
should it only occupy memory within the braces. I would have thought
the latter, but maybe this is not a requirement of standard C.

Definitely the latter (see section 6.2.4 of the standard). The former
behaviour is often achieved with the alloca() function.

The alloca() function is non-standard.

 

[Herbert Rosenau]

(e-mail address removed) (Michael) wrote...

In the below example, I beleive that the char array buffer[40] should
only occupy 40 bytes of the stack within the inner braces.

As far as the language specification is concerned automatic data will
only be allocated at the point of declaration, and will expire at the
end of the enclosing block scope.

No. You gets confused with visibility and reserved space. It is
completely legal theat an compuler will allocate the maximum used
space in asingle block for auto variables.

void f(void) {

if (x1)
{ int a[100]; }
if (x2)
{ int a; }
if (x3)
{
struct st {
int a, b, c, d;
double dd[999];
} s[10];
}

}

The compiler may or may not eleminate any unused variable - so giving
f() as above it may even eleminate any call of f() when the definition
of the function is visible, it may eleminate the whole body of the
fuction when it has nothing more as above, reducing it to a simple
return.

Assuming that each inner block has code that works with the variables
defined there it may allocate one single memory block big enough to
hold the biggest of all memory areas only while overlapping the
shorter ones, it may simply add the sizes and reserve the whole
storage or it can do whatever it likes to have the memory needed in
each block available. The only that the compiler will guarantee when
it defines itself as standard compatible is to have each variable only
visible in the block it is defined.

It may change its behavior depending on flags given to it at
compiletime. It may change its behavior between subversions or full
versions of itself.

There must not even a stack available. Any possible memory handling to
reserve a properitary chunk of memory that is used only inside the
function and its inner blocks and making the variables visible only
inside the inner blocks fullyfies the requirements of the standard
perfectly.

 

[Michael]

(e-mail address removed) (Michael) wrote in message

Thanks again to all who responded.