From owner-freebsd-stable Thu Oct 8 14:17:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22205 for freebsd-stable-outgoing; Thu, 8 Oct 1998 14:17:25 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22191 for ; Thu, 8 Oct 1998 14:17:15 -0700 (PDT) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40326>; Fri, 9 Oct 1998 07:16:33 +1000 Date: Fri, 9 Oct 1998 07:16:54 +1000 From: Peter Jeremy Subject: Re: Global register variables in gcc and stdio.h?!? To: freebsd-stable@FreeBSD.ORG Message-Id: <98Oct9.071633est.40326@border.alcanet.com.au> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: >I think you'll find in GCC that "register" is regarded as a weak hint at >best. Agreed. > The compiler is a whole >lot smarter about register allocation that you are, I disagree. The compiler bases its register allocation on a guess at the dynamic control flow, based on static data and control flow analysis. The actual control flow may be significantly different from gcc's guess - especially if a lot of code is rarely executed (eg exception handling code within a function). Also, gcc does not do any global (cross-function) analysis or optimisation. Threaded and bytecode interpreters (ie forth, e-lisp, java) generally have a small number of global variables which should be in registers - gcc can't work this out itself (but does have some extensions to allow then to be manually specified). Another problem with gcc's register allocation is that it doesn't re-order local variables within the stack frame. This means that variables that can't fit into registers (mostly because they're too large) sit at the top of the stack frame (closest to the frame pointer). Spilt registers go at the end of the stack frame. The net result of this is unnecessary code bloat. For example, on the x86 there is only a choice of 8 or 32-bit offsets - whilst the 32-bit offset has the same instruction timing, increasing the code size reduces the cache effectiveness, reducing speed. On the SPARC you need a 2 or 3-instruction sequence (and a work register) to access the variable once you exceed the 12-bit offset. > especially on an >architecture where there aren't any. Actually, on a true 0 or 1-address architecture, register allocation is trivial. The real difficulties occur with architectures that have a small number of registers which aren't quite all general purpose. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message