From owner-freebsd-alpha Sun Jul 21 14:58: 8 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0224737B400 for ; Sun, 21 Jul 2002 14:58:06 -0700 (PDT) Received: from alcanet.com.au (mail3.alcanet.com.au [208.178.117.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B9A543E3B for ; Sun, 21 Jul 2002 14:57:57 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from gsmx07.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1]) by alcanet.com.au (8.12.4/8.12.4/Alcanet1.3) with ESMTP id g6LLvg8R025832; Mon, 22 Jul 2002 07:57:42 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.3/8.12.3) with ESMTP id g6LLvg2h032699; Mon, 22 Jul 2002 07:57:42 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.3/8.12.3/Submit) id g6LLvgmS032698; Mon, 22 Jul 2002 07:57:42 +1000 (EST) Date: Mon, 22 Jul 2002 07:57:41 +1000 From: Peter Jeremy To: ticso@cicely.de Cc: Dag-Erling Smorgrav , Jan Lentfer , freebsd-alpha@FreeBSD.ORG Subject: Re: Size of Alpha binaries Message-ID: <20020722075741.D367@gsmx07.alcatel.com.au> Mail-Followup-To: ticso@cicely.de, Dag-Erling Smorgrav , Jan Lentfer , freebsd-alpha@FreeBSD.ORG References: <3D231418.1020406@web.de> <3D23160F.4070909@web.de> <20020703160226.GB70344@cicely5.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020703160226.GB70344@cicely5.cicely.de>; from ticso@cicely5.cicely.de on Wed, Jul 03, 2002 at 06:02:26PM +0200 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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