Date: Sat, 10 Oct 1998 13:42:19 +1000 From: Andrew Bromage <bromage@queens.unimelb.edu.au> To: Mike Smith <mike@smith.net.au>, marko@cs.uni-frankfurt.de Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Global register variables in gcc and stdio.h?!? Message-ID: <19981010134218.20700@queens.unimelb.edu.au> In-Reply-To: <199810071531.IAA00355@dingo.cdrom.com>; from Mike Smith on Wed, Oct 07, 1998 at 08:31:57AM -0700 References: <199810071330.PAA22126@king.ki.informatik.uni-frankfurt.de> <199810071531.IAA00355@dingo.cdrom.com>
index | next in thread | previous in thread | raw e-mail
G'day all. On Wed, Oct 07, 1998 at 08:31:57AM -0700, Mike Smith wrote: > 1) Any application which depends on global register variables for > performance needs to be fixed. At the risk of getting off-topic, there is at least one exception, and that's compiler-generated code. Many languages use C as a target language because it neatly fills the niche of "platform-independent assembly language". Compiler-generated C is usually the sort of C which had a programmer hand-written it, there would be good cause to sack said programmer. Generated C doesn't need to be maintained, so it can use as many weird features like global register variables or non-local gotos as it likes. In the case of Mercury, the application in question, the global register variables are for parameter passing. There's good reason to do this: C only allows one parameter to be returned from a function, whereas Mercury allows multiple return parameters, so to avoid the performance hit of either passing pointers or packing the return arguments up in a struct (GCC doesn't do a very good job at optimising the latter case), we use global register variables. This causes a significant speedup compared with C on simple benchmarks which are craftily designed to use lots of multiple return parameters, so we feel justified in this design choice. > The concept of a "global register > variable" on the x86 is a bit of a joke anyway. Very true. We have to generate separate object files for position- independent code for the x86 because PIC grabs one more register than we're willing to pay for in position-dependent code. > 2) Declare your global register variables before including header > files. This was the fix to the bug. :-) If anyone else wants to discuss this further, I invite you to do so off-list. Cheers, Andrew Bromage To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the messagehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981010134218.20700>