Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!nbires!hao!husc6!rutgers!rochester!PT!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: Big Programs Hurt Performance
Message-ID: <2614@aw.sei.cmu.edu>
Date: Wed, 23-Sep-87 17:14:41 EDT
Article-I.D.: aw.2614
Posted: Wed Sep 23 17:14:41 1987
Date-Received: Sat, 26-Sep-87 07:53:32 EDT
References: <417@devvax.JPL.NASA.GOV> <12780006@acf4.UUCP>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu.UUCP (PUT YOUR NAME HERE)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 23

In article <12780006@acf4.UUCP> tihor@acf4.UUCP (Stephen Tihor) writes:
>N excelemnt summary on shared libraries but I would not agree that Position
>Independant Code is difficult to produce. 95+% of the code I produce is PIC
>and with a more clever linker (as one would expect in that enviornment) it
>could get higher.  Only systems whose instruction set was not designed with PIC
>as a goal make it hard.

I'd agree with this.  PIC is either easy or impossible, but rarely hard.
For instance, if your machine has only conditional branches with absolute
addresses as the operand, then it's impossible.

Taking the PDP-11 as another example, I added a PIC option to a
codegenerator with about one week's work, including testing &
documentation of the differences in the generated code.  Under
this option, code was between 2% and 10% bigger, the last an extreme
case where a lot of addresses of static read-only variables were
being generated.  PIC for the CA NM4 was designed in an afternoon
and it took the implementor about 3 days to put it in.

This is such a useful technique, that I think every machine ought
to support position-independent code.  Really all you need are
PC-relative control transfers, global base registers, and for
efficiency a load-address instruction.