FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s
tmm at freebsd.org
Mon Feb 16 16:26:50 PST 2004
On Mon, 2004/02/16 at 19:11:16 +0100, Dag-Erling Smørgrav wrote:
> Kris Kennaway <kris at obsecurity.org> writes:
> > On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote:
> > > Should I commit this?
> > What effect does it have on non-i386 architectures?
> It can't possibly hurt. If the stack is already aligned on a "better"
> boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary
> since 64 and 128 are multiples of 32, and the patch is a no-op. If
> only a 16-byte alignment is required, a 32-byte alignment wastes a
> small amount of memory but does not hurt performance. I believe that
> less-than-16 (and possibly even less-than-32) alignment is pessimal on
> all platforms we support.
Well, it misaligns stack_base on 64-bit architectures, for example
(notice the "- 4", which is there to compensate for the fixup in
kern_execve() that will subtract another sizeof(register_t)):
vectp = (char **)(((vm_offset_t)vectp & ~(vm_offset_t)0x1F) - 4);
It would by much better to be able to align the stack in
exec_setregs(), like amd64, ia64, powerpc and sparc64 do.
Unfortunately that would require changes to crt1, so it would pose a
Thomas Moestl <t.moestl at tu-bs.de> http://www.tu-bs.de/~y0015675/
<tmm at FreeBSD.org> http://people.FreeBSD.org/~tmm/
"Oh, great altar of passive entertainment... Bestow upon me thy
discordant images at such speed as to render linear thought
impossible!" -- Calvin and Hobbes
More information about the freebsd-hackers