Re: stack allocation and gcc

[Ihar 'Philips' Filipau]

Jaco Kroon wrote:
> Hi Ihar,
>
> In your code you have 3 buffers, one in the mani branch of 32 bytes and 
> one of 32 bytes in each of the sub branches.  This adds up to a total of 
> 64 bytes since as you say, the two buffers named buf2[32] can be 
> shared.  Thus it is 32 bytes for buf and 32 bytes for the shared 
> buffer.  Now if you look at the function startup code:
>
>   0:   55                      push   %ebp
>   1:   89 e5                   mov    %esp,%ebp
>   3:   83 ec 68                sub    $0x68,%esp
>
> THe push saves the frame pointer (ebp).  The mov sets up the new stack 
> frame and the sub allocates space of 68 bytes on the stack, 4 bytes more 
> than the expected 64, this is probably for temporary storage required 
> somewhere in the function.  As such, gcc does not allocate 32 bytes too 
> many (at least not on i386, but probably not on other architectures 
> either).
>
> Jaco

  0x68 != 68.

  [ All known to me assemblers on ix86 use hexadecimal number by 
default. I was sort of surprised to find out that ppc gas uses decimal 
numbers only. ]

  0x68 == 104 == 32*3 + 4 + 4.

  As I have said, keep adding to function 'do { char buf[32]; 
printf(buf); } while(0)' increse this number. As in my logic it is 
supposed to be unchanged - all renundant buffers do have same size - 32 
bytes.

--
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--                                                           _ _ _
 "... and for $64000 question, could you get yourself       |_|*|_|
   vaguely familiar with the notion of on-topic posting?"   |_|_|*|
                                -- Al Viro @ LKML           |*|*|*|
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/