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?"