Date: Mon, 22 Jul 2002 07:57:41 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: ticso@cicely.de Cc: Dag-Erling Smorgrav <des@ofug.org>, Jan Lentfer <Jan.Lentfer@web.de>, freebsd-alpha@FreeBSD.ORG Subject: Re: Size of Alpha binaries Message-ID: <20020722075741.D367@gsmx07.alcatel.com.au> In-Reply-To: <20020703160226.GB70344@cicely5.cicely.de>; from ticso@cicely5.cicely.de on Wed, Jul 03, 2002 at 06:02:26PM %2B0200 References: <3D231418.1020406@web.de> <xzpofdo6dt1.fsf@flood.ping.uio.no> <3D23160F.4070909@web.de> <xzpfzz06di0.fsf@flood.ping.uio.no> <20020703160226.GB70344@cicely5.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 03, 2002 at 06:02:26PM +0200, Bernd Walter wrote: >And it's a RISC architecture >no complex instructions - that means you often need more instructions. >And all instructions are equal in length, while i386 has some shorter >instructions. Actually, I doubt this has much impact overall. Toy IA32 code can be quite dense but real IA32 code tends to have quite a low density - more comparable with SPARC than M68K (even the RISC-ified ColdFire is denser than IA32 in my experience). Whilst the IA32 does have shorter instructions, it also has longer ones. Other reasons for IA32 bloat are: - Lack of 16-bit offsets. Once a stack frame exceeds 127 bytes, you use 32-bit offsets (typically 6-byte instructions). - Lack of registers. This translates to more memory references and more local variables wind up on the stack. - GCC's (at least up to around 2.7, I haven't looked recently) stack frame allocation algorithm puts large objects (that aren't eligible for register storage) at the top of the frame. Pseudo-registers that fail to get hardware registers are spilled after large objects (further from the frame pointer). - Current IA32 implementations use RISC-like cores and pessimize the CISCier instructions. Avoiding the complex instructions generally gives faster (though larger) code. The first 3 points all mutually conspire to maximise code size. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020722075741.D367>