Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Feb 2004 16:59:57 -0800
From:      Tim Kientzle <kientzle@acm.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5)
Message-ID:  <4031678D.2060704@acm.org>
In-Reply-To: <200402162112.i1GLCFMV087316@apollo.backplane.com>
References:  <BAY12-F357RapPBVToy00031029@hotmail.com> <200402162112.i1GLCFMV087316@apollo.backplane.com>

index | next in thread | previous in thread | raw e-mail

Matthew Dillon wrote:
>     I'm surprised Bruce hasn't chimed in here yet.  I guess he's tired of
>     repeating himself.
> 
>     In 4.9, libcsu, which generates crt1.o (which is the start code for
>     C programs which the linker links in automatically) has this line in it:
> 
> 	    andl    $~0xf, %%esp            # align stack to 16-byte boundary
> 
>     So anything linked with 4.9 is going to align the stack on a 
>     16 byte boundary no matter WHAT the kernel does.
> 
>     FreeBSD-5 does not have this alignment in its crt1.o because GCC3
>     automatically aligns the stack on a per-procedure basis.  Or at least
>     it is supposed to.  Maybe it's broke?  :-)

I've not looked at 3.3, but I seem to recall that GCC 3.2
did not actually align the stack within each function, but
preserved the alignment.  (That is, each function assumed the stack
had a certain alignment on entry and ensured that alignment
was preserved for any subsequent function calls.)

I had my doubts about this, as it meant there was a LOT
of stack fiddling before and after every function call.
(The alignment was handled at caller, not callee.  A lot of
functions don't need any alignment at all, really, so
it seems like it could be wasted effort in a lot of cases.)

If I'm remembering this correctly, then aligning
the stack in crt1.o would be pretty much essential.

Tim Kientzle


help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4031678D.2060704>