question about allocating local variable

question about allocating local variable

[Prawit Chaivong]

My question is... 
I wrote the program like this.
 
void func()
{
  char a[8];
}

And then compile to asm code I've got this line of
code.

.....
subl $8 %esp
.....

That makes sense, It moves stack pointer down 8 bytes
for local variable.
But the problem is, when I change size of array to 9
or 7 the asm code turn to this.

....
subl $24 %esp
....

It doesn't make any sense to me. Why it allocates 24
bytes for 9 or 7 bytes variable.

Does anybody has any explaination?

Thank in advance.
Prawit C.


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: question about allocating local variable

[Eljay Love-Jensen]

Hi Prawit,

 >Does anybody has any explaination [why the compiler allocates more than 
specified]?

Alignment.

You didn't specify what platform, GCC version (3.3.4?  3.4.0?), and compile 
options you are using.  If you are not generated optimized code, the code 
may not be optimized.

It is also possible that one of the GCC Gnurus made a boo-boo.  Rare, but 
can happen.  Especially between optimizations that are in contention, which 
may have unintended side-effects on different platforms.  (I discovered 3 
such issues, on GCC 2.95 on Solaris.  They're all fixed now.)

HTH,
--Eljay

Re: question about allocating local variable

[Purnendu/Gmail]

On a solaris platform with gcc 3.0 the one i have
out put for such a behaviour is pretty predictive.

It allocates a stack of 120 for char a[1] to char a[8]
then 128 for char a[9] to char a[16]
and so on.

for an integer array
It allocates a stack of 120 for int a[1] and int a[2]
then 128 for int a[3] to int a[4]
and so on.

with a allignment of 4 bytes

===============

 .file   "help.c"
        .section        ".text"
        .align 4
        .global main
        .type   main,#function
        .proc   04
main:
        !#PROLOGUE# 0
        save    %sp, -128, %sp
        !#PROLOGUE# 1
        ret
        restore
.LLfe1:
        .size   main,.LLfe1-main
        .ident  "GCC: (GNU) 3.0"
~



 


===============


Hope i am correct.am i?
but then why the initial 120 bytes,???

On Mon, 28 Jun 2004 10:50:13 -0500, Eljay Love-Jensen <eljay@adobe.com> wrote:
> 
> Hi Prawit,
> 
> >Does anybody has any explaination [why the compiler allocates more than
> specified]?
> 
> Alignment.
> 
> You didn't specify what platform, GCC version (3.3.4?  3.4.0?), and compile
> options you are using.  If you are not generated optimized code, the code
> may not be optimized.
> 
> It is also possible that one of the GCC Gnurus made a boo-boo.  Rare, but
> can happen.  Especially between optimizations that are in contention, which
> may have unintended side-effects on different platforms.  (I discovered 3
> such issues, on GCC 2.95 on Solaris.  They're all fixed now.)
> 
> HTH,
> --Eljay
> 
>

Re: question about allocating local variable

[Eljay Love-Jensen]

Hi Pernendu,

 >but then why the initial 120 bytes,???

Probably has to do with compliance to SPARC ABI 
(http://www.sparc.com/standards/psABI3rd.pdf) specifications.

--Eljay

Re: question about allocating local variable

[llewelly]

Purnendu/Gmail <purnendu@gmail.com> writes:

> On a solaris platform with gcc 3.0 the one i have
> out put for such a behaviour is pretty predictive.
> 
> It allocates a stack of 120 for char a[1] to char a[8]
> then 128 for char a[9] to char a[16]
> and so on.
> 
> for an integer array
> It allocates a stack of 120 for int a[1] and int a[2]
> then 128 for int a[3] to int a[4]
> and so on.
> 
> with a allignment of 4 bytes
> 
> ===============
> 
>  .file   "help.c"
>         .section        ".text"
>         .align 4
>         .global main
>         .type   main,#function
>         .proc   04
> main:
>         !#PROLOGUE# 0
>         save    %sp, -128, %sp

This isn't just for your array. Most of it is for saving the register
    stack. 

>         !#PROLOGUE# 1
>         ret
>         restore
> .LLfe1:
>         .size   main,.LLfe1-main
>         .ident  "GCC: (GNU) 3.0"
> ~
[snip]

Re: question about allocating local variable

[Prawit Chaivong]

--- Eljay Love-Jensen <eljay@adobe.com> wrote:
> Hi Prawit,
> 
>  >Does anybody has any explaination [why the
> compiler allocates more than 
> specified]?
> 
> Alignment.

If we need char a[9] and the compiler allocated 12
bytes for me. That makes sense. But I'm wondering why
I need 9 bytes but compiler allocated 24 bytes.
I might misunderstand about alignment. And I will be
appreciate if you could tell me why it gonna be that
way.

> 
> You didn't specify what platform, GCC version
> (3.3.4?  3.4.0?), and compile 
> options you are using.  If you are not generated
> optimized code, the code 
> may not be optimized.
> 

gcc 2.96 on x86 And asm code are the same no matter
what you gonna optimized or not.

> It is also possible that one of the GCC Gnurus made
> a boo-boo.  Rare, but 
> can happen.  Especially between optimizations that
> are in contention, which 
> may have unintended side-effects on different
> platforms.  (I discovered 3 
> such issues, on GCC 2.95 on Solaris.  They're all
> fixed now.)
> 
> HTH,
> --Eljay
> 
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: question about allocating local variable

[Eljay Love-Jensen]

Hi Prawit,

 >And I will be appreciate if you could tell me why it gonna be that way.

I presume it is due to allocated space for register backing stores.

Granted, in lovingly hand-crafted assembly, you may dispense with over 
reserved stack space through meticulous care.

In this situation, GCC seems to over-allocate the stack beyond what it 
strictly needs (moreso than just alignment).  Considering that the small 
routine I wrote is a leaf-node (doesn't call any other subroutines).

 >gcc 2.96 on x86

There is no "GCC 2.96" -- there's a Red Hat 2.96, which is a maverick / 
rogue release.  Red Hat 2.96 is not supported in this forum; it may be 
supported by Red Hat.

That being said, GCC 3.3.1 on Cygwin / WinNT has the same behavior.

You may want to try the current releases of GCC, either GCC 3.3.4 or GCC 3.4.0.

 >And asm code are the same no matter what you gonna optimized or not.

Okay, I've confirmed that with -O0 and -O3 on my platform.

--Eljay