lkml.org 
[lkml]   [2004]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: stack allocation and gcc
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2005-03-22 14:01    [from the cache]
©2003-2011 Jasper Spaans