Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Is the Intel memory model safe from NO-ONE ?!?
Message-ID: <1988May15.221641.13091@utzoo.uucp>
Organization: U of Toronto Zoology
References: <3384@drivax.UUCP>, <4053@killer.UUCP>
Date: Sun, 15 May 88 22:16:41 GMT

> There's one case where segmentation (of code) is a Big Win...  Shared
> libraries. ...Sys V.3 has a kludge that reserves various places in a
> (linear) 32-bit address space for certain libraries and types of libraries.
> This is necessary because the libraries must appear at the same address in
> every process...  On a segmented machine, all shared libraries could start
> at address 0, in different segments in different processes. It is a much
> more elegant solution...

This depends an awful lot on the details of your MMU.  In particular, the
problem with shared libraries is usually not code, but data:  it's not
that big a deal to make the code position-independent on most machines,
but doing that for data is usually a colossal pain.  Segmentation is a win
only if the segment numbers of shared-library code and data can be chosen
at run time without performance penalty.  Otherwise it's the same as taking
a 32-bit linear address space and calling the top 8 bits "segment number"
and the bottom 24 "offset".

Contrariwise, if a 32-bit-linear-address machine has some careful support
for shared libraries, as in National's 32000 series for example, it can
do exactly the same things as a segmented machine.

The fundamental requirement for efficient relocatable shared libraries is
the ability to choose the address of a shared library's data (and code) at
run-time without having to alter the code or use grossly slow address
arithmetic everywhere.  Support for this is quite independent of what sort
of address space you have:  some linear-address machines can do it, and some
segmented ones can't.
-- 
NASA is to spaceflight as            |  Henry Spencer @ U of Toronto Zoology
the Post Office is to mail.          | {ihnp4,decvax,uunet!mnetor}!utzoo!henry