Path: utzoo!attcan!uunet!husc6!think!ames!killer!elg
From: elg@killer.UUCP (Eric Green)
Newsgroups: comp.arch
Subject: Re: Is the Intel memory model safe from NO-ONE ?!?
Message-ID: <4053@killer.UUCP>
Date: 12 May 88 05:28:27 GMT
References: <3384@drivax.UUCP>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 31

in article <3384@drivax.UUCP>, alexande@drivax.UUCP says:
> In article <353@cf-cm.UUCP> mch@computing-maths.cardiff.ac.uk (Major Kano)
> writes about:
>>... the advantages of segmenting, ie., ease of doing
>>relocatable code, logical program design (code, data/heap stack separation),
>>inter-task separation (LDT's) and a few other related features.
> 
> Maybe I'm slow, but I can't see how segmentation makes these things
> much easier, compared with a typical non-segmented paging system.  We
> did a port of FlexOS to both the 386 and the NEC V60, and the V60 was
> actually easier to deal with precisely because we didn't have to muck
> with all that segment stuff.

There's one case where segmentation (of code) is a Big Win (segmentation of
data space is almost never a win): Shared libraries. I understand that 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 (because otherwise
they would need to be re-linked for each process, on most machines, which
don't support relocatable code -- thus throwing away all the advantages of
shared libraries).

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
than chopping your address space in such a manner that you cannot have two
windowing libraries loaded at the same time.  

--
    Eric Lee Green                     {cuae2,ihnp4}!killer!elg
         Snail Mail P.O. Box 92191 Lafayette, LA 70509              
"Is a dream a lie that don't come true, or is it something worse?"