Home > Archive > C > June 2006 > allocating space for local variables
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
allocating space for local variables
|
|
| junky_fellow@yahoo.co.in 2006-06-26, 3:57 am |
| Hi guys,
Consider the following piece of code:
func()
{
if(x==0) {
int arr[50];
/* do something */
}
else {
int arr2[100];
/* do something */
}
}
I wanted to know, if the space of arr[50 is allocated only when the
condition "x==0" is
true or the space is allocated when the function "func" is called.
I am working on an m68k implementation where the local varialbles are
allocated
on stack. I would be really grateful if anyone can provide me an
answer for an m68k
implementation.
thanks a lot for any help in advance ...
| |
| Nils O. Selåsdal 2006-06-26, 3:57 am |
| junky_fellow@yahoo.co.in wrote:
> Hi guys,
>
> Consider the following piece of code:
>
> func()
> {
>
> if(x==0) {
> int arr[50];
> /* do something */
> }
> else {
> int arr2[100];
> /* do something */
> }
> }
>
>
> I wanted to know, if the space of arr[50 is allocated only when the
> condition "x==0" is
> true or the space is allocated when the function "func" is called.
> I am working on an m68k implementation where the local varialbles are
> allocated
> on stack. I would be really grateful if anyone can provide me an
> answer for an m68k
The answer would be compiler dependant, compiler flags dependant, and
code dependant. Some code , depending on the optimizations/etc. might be
reordered to play things out very differently than just some very
slightly different code.
Your best bet is to p at the assembly(if available - gcc -S for gcc)
generated for the exact code you have compiled with the options you'll
be using in "production".
| |
| Frederick Gotham 2006-06-26, 7:56 am |
| junky_fellow@yahoo.co.in posted:
> Hi guys,
>
> Consider the following piece of code:
>
> func()
> {
>
> if(x==0) {
> int arr[50];
> /* do something */
> }
> else {
> int arr2[100];
> /* do something */
> }
> }
>
>
> I wanted to know, if the space of arr[50 is allocated only when the
> condition "x==0" is
> true or the space is allocated when the function "func" is called.
> I am working on an m68k implementation where the local varialbles are
> allocated
> on stack. I would be really grateful if anyone can provide me an
> answer for an m68k
> implementation.
>
> thanks a lot for any help in advance ...
You could use an anonymous union. (Please correct me if they're not
Standard C).
union {
int arr[50];
int arr2[100];
};
--
Frederick Gotham
| |
| deepak 2006-06-26, 6:56 pm |
|
Nils O. Sel=E5sdal wrote:
> junky_fellow@yahoo.co.in wrote:
>
> The answer would be compiler dependant, compiler flags dependant, and
> code dependant. Some code , depending on the optimizations/etc. might be
> reordered to play things out very differently than just some very
> slightly different code.
>
Please correct me if i'm wrong.
Memory will be allocated for both arrays since it happens at
compilation time.
Here malloc comes into picture. It 'll do it at run time.
Once again i'm telling it's only my understanding. If wrong correct me.
> Your best bet is to p at the assembly(if available - gcc -S for gcc)
> generated for the exact code you have compiled with the options you'll
> be using in "production".
| |
| Al Balmer 2006-06-26, 6:56 pm |
| On 26 Jun 2006 01:38:56 -0700, "junky_fellow@yahoo.co.in"
<junky_fellow@yahoo.co.in> wrote:
>Hi guys,
>
> Consider the following piece of code:
>
> func()
> {
>
> if(x==0) {
> int arr[50];
> /* do something */
> }
> else {
> int arr2[100];
> /* do something */
> }
> }
>
>
> I wanted to know, if the space of arr[50 is allocated only when the
>condition "x==0" is
> true or the space is allocated when the function "func" is called.
> I am working on an m68k implementation where the local varialbles are
>allocated
> on stack. I would be really grateful if anyone can provide me an
>answer for an m68k
> implementation.
>
In the context of this newsgroup, you don't know and should not care
when the allocation takes place. You must write code as if it took
place at the beginning of the block. For your particular problem, I
suggest you post on comp.arch.embedded, and provide more detail about
the implementation you're using.
--
Al Balmer
Sun City, AZ
| |
|
|
| Tom St Denis 2006-06-26, 6:56 pm |
| deepak wrote:
> Please correct me if i'm wrong.
> Memory will be allocated for both arrays since it happens at
> compilation time.
> Here malloc comes into picture. It 'll do it at run time.
>
> Once again i'm telling it's only my understanding. If wrong correct me.
This is where it pays to actually earn your post-secondary degree...
No, first off there is no runtime call to malloc.
Second, the implementation is free to either allocate enough memory to
hold the largest of the two (note that you can't access both
simultaneously) or allocate it as required.
By allocate I mean "make available". That may be a call to malloc
(likely it won't be) or a call to alloca() or just subtract the stack
pointer or .... .... ... it's not predefined. Recent releases of GCC
[by that I mean 3.x series and up] will analyze the function and
allocate stack in the preamble. But that is just how GCC chooses to do
it.
Tom
| |
| Jack Klein 2006-06-26, 6:56 pm |
| On 26 Jun 2006 07:48:31 -0700, "deepak" <deepakpjose@gmail.com> wrote
in comp.lang.c:
>
> Nils O. Selåsdal wrote:
>
> Please correct me if i'm wrong.
Consider yourself corrected.
> Memory will be allocated for both arrays since it happens at
> compilation time.
That is true for objects with static storage duration, specifically
all objects defined at file scope or with the 'static' keyword.
Automatic objects do not need to be allocated until the block
containing their definition is entered.
[color=darkred]
> Here malloc comes into picture. It 'll do it at run time.
>
> Once again i'm telling it's only my understanding. If wrong correct me.
>
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~.../FAQ-acllc.html
| |
| Richard G. Riley 2006-06-26, 6:56 pm |
| "junky_fellow@yahoo.co.in" <junky_fellow@yahoo.co.in> writes:
> Hi guys,
>
> Consider the following piece of code:
>
> func()
> {
>
> if(x==0) {
> int arr[50];
> /* do something */
> }
> else {
> int arr2[100];
> /* do something */
> }
> }
>
>
> I wanted to know, if the space of arr[50 is allocated only when the
> condition "x==0" is
> true or the space is allocated when the function "func" is called.
> I am working on an m68k implementation where the local varialbles are
> allocated
> on stack. I would be really grateful if anyone can provide me an
> answer for an m68k
> implementation.
I'm interested in to why you would need to determine the difference even
assuming non portable code and the assertion that all locals are stack
based.
It cant be a memory thing since I assume x<>0 at some stage anyway so
you need to assume the stack space required for at leas 100 integers.
>
> thanks a lot for any help in advance ...
>
--
Lint early. Lint often.
| |
| robertwessel2@yahoo.com 2006-06-26, 6:56 pm |
|
Tom St Denis wrote:
> deepak wrote:
>
> This is where it pays to actually earn your post-secondary degree...
>
> No, first off there is no runtime call to malloc.
>
> Second, the implementation is free to either allocate enough memory to
> hold the largest of the two (note that you can't access both
> simultaneously) or allocate it as required.
The implementation is also free to allocate both areas on the stack (if
such a thing is being used) at entry to the routine, or one on the
stack and the other dynamically, or...
Commonly these will be allocated on the stack as if they had been in a
union.
| |
| Kenneth Brody 2006-06-26, 6:56 pm |
| "junky_fellow@yahoo.co.in" wrote:
>
> Hi guys,
>
> Consider the following piece of code:
>
> func()
> {
>
> if(x==0) {
> int arr[50];
> /* do something */
> }
> else {
> int arr2[100];
> /* do something */
> }
> }
>
> I wanted to know, if the space of arr[50 is allocated only when the
> condition "x==0" is
> true or the space is allocated when the function "func" is called.
> I am working on an m68k implementation where the local varialbles are
> allocated
> on stack. I would be really grateful if anyone can provide me an
> answer for an m68k
> implementation.
>
> thanks a lot for any help in advance ...
Well, the only way to know how it's done on your implementation would
be to examine the code that is generated by your compiler. However,
as has been pointed out, it's possible for this to change if you use
different flags to the compiler, let alone use a different compiler
altogether.
I've seen compilers that adjust the local stack frame when entering
the relevent section of code, allocating the local variables in that
stack space, and re-adjusting the stack frame upon leaving the
section. I've seen others that allocate enough stack space based on
the largest amount that would be needed by any particular section of
code, and then do the equivalent of a union on the stack, with each
section of code using the same stack memory for their own local
variables.
Finally, as others have pointed out, why should it matter?
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap@gmail.com>
| |
| Al Balmer 2006-06-26, 6:56 pm |
| On Mon, 26 Jun 2006 18:12:20 +0200, "Richard G. Riley"
<rgriley@gmail.com> wrote:
>"junky_fellow@yahoo.co.in" <junky_fellow@yahoo.co.in> writes:
>
>
>I'm interested in to why you would need to determine the difference even
>assuming non portable code and the assertion that all locals are stack
>based.
>
>It cant be a memory thing since I assume x<>0 at some stage anyway so
>you need to assume the stack space required for at leas 100 integers.
The OP is probably working on an embedded system with memory
constraints. It may be important to know whether he needs to assume
the space required for 100 integers or 150 integers.[color=darkred]
>
--
Al Balmer
Sun City, AZ
| |
| Richard G. Riley 2006-06-26, 6:56 pm |
| Al Balmer <albalmer@att.net> writes:
> On Mon, 26 Jun 2006 18:12:20 +0200, "Richard G. Riley"
> <rgriley@gmail.com> wrote:
>
>
> The OP is probably working on an embedded system with memory
> constraints. It may be important to know whether he needs to assume
> the space required for 100 integers or 150 integers.
Both of which are possible so you need to plan for worst case I would
have thought.
| |
| Al Balmer 2006-06-26, 6:56 pm |
| On Mon, 26 Jun 2006 19:42:30 +0200, "Richard G. Riley"
<rgriley@gmail.com> wrote:
>
>Both of which are possible so you need to plan for worst case I would
>have thought.
Nope, not when doing embedded systems. You need to determine what the
actual worst case is for your hardware and language implementation,
not the worst possible case for any implementation.
That's why this is off-topic here, and the OP will get better advice
in another newsgroup.
--
Al Balmer
Sun City, AZ
| |
| Nils O. Selåsdal 2006-06-26, 6:56 pm |
| deepak wrote:
> Nils O. Selåsdal wrote:
>
> Please correct me if i'm wrong.
> Memory will be allocated for both arrays since it happens at
> compilation time.
> Here malloc comes into picture. It 'll do it at run time.
The implementation(compiler...) is free to do whatever it wants
as long as the meaning doesn't change. It's not uncommon for
an optimizing C compiler to turn your C code upside down and
whatnot comparing it to the assembly/machinecode it might emit.
(e.g. you might assume
void freelist(Node *n) {
if(n != NULL) {
Node *next = n->next;
free(n);
freelist(next);
}
}
takes space proportional to the length of the list as it recurses down.
I was happy to see the C compiler I use effectivly turn the above to a
goto loop involving no recursive calls - aka tail call optimization :-)
| |
| Keith Thompson 2006-06-26, 6:56 pm |
| "Nils O. Selåsdal" <NOS@Utel.no> writes:
> junky_fellow@yahoo.co.in wrote:
>
> The answer would be compiler dependant, compiler flags dependant, and
> code dependant. Some code , depending on the optimizations/etc. might be
> reordered to play things out very differently than just some very
> slightly different code.
>
> Your best bet is to p at the assembly(if available - gcc -S for gcc)
> generated for the exact code you have compiled with the options you'll
> be using in "production".
Another approach would be to examine the addresses of the array
objects, either using printf with a "%p" format (and the required cast
to void*) or a debugger. With some reasonable assumptions about how
memory is allocated, this should tell you what you need to know.
But of course the results will be specific to whatever compiler you're
using, and possibly to the options with which you invoke it.
The answer is unlikely to depend on the fact that you're using an
m68k. Different compilers for the same CPU are free to do this
differently; so is the same compiler with different options.
If your compiler allocates 150 bytes for arr and arr2 (with
appropriate optimization options), consider complaining to your
vendor. It's not a violation of the standard, but it's a waste of
space since arr and arr2 cannot exist simultaneously.
A compiler could reasonable allocate max(sizeof arr, sizeof arr2) on
entry to the function, or allocate just enough for a single array on
entry to the block contaiing its declaration. The latter saves space
in some cases at the expense of some extra code.
If you're desparate for space *and* your compiler doesn't do the
optimization you need, you can combine the declarations yourself,
being careful to guarantee that you always allocate enough space for
the object you need. The simplest way to do this would be to put arr
and arr2 in separate functions, though that imposes some additional
overhead as well.
Discussion more detailed than this should probably go to
comp.arch.embedded or to some system-specific newsgroup.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
| |
| Mark McIntyre 2006-06-26, 6:57 pm |
| On 26 Jun 2006 07:48:31 -0700, in comp.lang.c , "deepak"
<deepakpjose@gmail.com> wrote:
>Please correct me if i'm wrong.
>Memory will be allocated for both arrays since it happens at
>compilation time.
As someone said earlier, its compiler and optimiser dependent.
--
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
|
|
|
|
|