From owner-freebsd-hackers  Sat Aug 30 19:34:16 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA13776
          for hackers-outgoing; Sat, 30 Aug 1997 19:34:16 -0700 (PDT)
Received: from ducky.net (gate.ducky.net [198.145.101.253])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA13762;
          Sat, 30 Aug 1997 19:34:07 -0700 (PDT)
Received: (from mike@localhost)
	by ducky.net (8.8.5/8.8.5) id TAA00415;
	Sat, 30 Aug 1997 19:33:49 -0700 (PDT)
Date: Sat, 30 Aug 1997 19:33:49 -0700 (PDT)
From: Mike Haertel <mike@ducky.net>
Message-Id: <199708310233.TAA00415@ducky.net>
To: dyson@FreeBSD.ORG
Subject: Re: PIC (was: shared libraries?)
Cc: hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

John S. Dyson wrote:
>Basically, PIC requires the use of an additional base register.  That
>adds register pressure and complicates the needed addressing modes.  There
>are only 6 or 7 registers to begin with on an X86.  Please look at the
>code that gcc creates with the -fpic option.  It isn't gcc's fault that
>the code looks more complex.  It seems that the X86 could use at least a
>few more registers :-(, but there are always design tradeoffs.

One thing that's always baffled me is, why does gcc insist
on *dedicating* a register for the global offset table pointer?

I would hope that instead of dedicating a register, they would
just make the global offset table pointer a regular variable
subject to register allocation just like any other variable.
Then, code that doesn't use global variables wouldn't be hurt
by being put in a shared library.