Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!sdcsvax!darrell
From: barry@adelie.Adelie.COM (Barry A. Burke)
Newsgroups: comp.os.research,mod.os
Subject: Re: Shared Libraries
Message-ID: <3047@sdcsvax.UCSD.EDU>
Date: Sun, 26-Apr-87 21:50:37 EDT
Article-I.D.: sdcsvax.3047
Posted: Sun Apr 26 21:50:37 1987
Date-Received: Tue, 28-Apr-87 03:07:57 EDT
Sender: darrell@sdcsvax.UCSD.EDU
Organization: Adelie Corporation, Cambridge MA
Lines: 54
Approved: mod-os@sdcsvax.uucp
Xref: mnetor comp.os.research:17 mod.os:157


In article <2990@sdcsvax.UCSD.EDU> rab@mimsy.UUCP (Robert A Bruce) writes:
>There is no shared memory between processor boards, so moving a process
>to a different cpu requires copying the entire text space.
What a bummer. Shared memory space would save you TONS! of overhead. Process
exchange overhead is what causes 16 1MIP processors != 16MIPS. 

Beleive it or not, at Prime several years ago we built the Prime 850 out of
two closely coupled 750's. After a whiz engineer (Hi, Dave!) resolved the
issues of instruction pipeline re-initialization, it became possible for a
process to be suspended by the scheduler on CPU A, and then continue on CPU B.
Of course, the Prime 50 series architecture made all this possible through
it's process register management: A processes' entire register set (including
instruction pointer, etc.) could be mapped into any one of the (2, 4, 8,
16-depending on CPU model) CPU register sets in microseconds. Process exchange
consisted of flopping (1,2,3,4) bits - something the 750 could do 40,000
times/second. The 850 used a 1Kb "window" to share these register sets between
the two 750 CPU's.

Bottom line? 2*750 = 2.2*750! Why? becuase all interrupt processies could only
run on one of the CPU's, (leaving only about 90% for user's) The second CPU
was 100% available for user processies. So 1*750=.9, 2*750=1.9, 1.9/.9=2.2
(almost)... 

>use shared libraries the size of the text segment of each process whould 
>be substantially reduced, so copying could be done much more efficiently.
>
>1) Locate the library at a know location in memory.  At link time bind
>   all the addresses to the addresses of the library subroutines.

Bad news. Prime Originally did this- turns out the pain of having to recompile
really makes customer's mad...
>
>2)  Same as 1) but bind all the addresses when a program is loaded.

Expensive, but on the right track (see next item).

>
>3)  Use a jump table.  The jump table is located at a known location in
>    memory. 

Almost...

>4)  Use an `openlibrary' system call that returns a pointer to a table
>    of pointers to library routines.  I have heard the amiga uses

Hooray! Whatthey did at Prime is create a subroutine call structure in the
loaded program that looks like this (in layman's terms):

	jump indirect address
	

address INSTRUCTION FAULT
	"name of routine"