Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!ucbvax!jade!eris!mwm From: mwm@eris.UUCP Newsgroups: comp.sys.intel,comp.lang.c,comp.arch Subject: Re: segments and Unix Message-ID: <1744@jade.BERKELEY.EDU> Date: Fri, 21-Nov-86 20:25:49 EST Article-I.D.: jade.1744 Posted: Fri Nov 21 20:25:49 1986 Date-Received: Sun, 23-Nov-86 03:25:52 EST References: <13802@amdcad.UUCP> <1217@peregrine.UUCP> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) Followup-To: comp.arch Organization: Missionaria Phonibalonica Lines: 34 Xref: watmath comp.sys.intel:51 comp.lang.c:148 comp.arch:61 Just a few quick observations on segments: 1) Segments are not a new thing - Burroughs has been selling them on their large systems for over a decade now (two decades, maybe?). 2) The thing that everybody who works with unix should think of when the word "segments" comes up (after eighty-eighty sux, of course :-) is "Multics," followed by "slow." But Multics tried to support far more than is being discussed here. 3) Segments are a good thing, but only if you've got enough to be usefull (enough to store arrays as illith vectors), and each one is big enough to be ditto. "Enough" varies with time, of course. 4) You don't have to have a time overhead for having segments. After all, a VAX has segments already. 5) You don't have to have broken pointer semantics if you use segments. Scattering them around in a large, sparse address space works fine. 6) 32 bits isn't a big enough address space. You can (maybe) make something usefull out of it, but it probably won't be usefull in a few years. 7) The memory cost for segments should be small, and may be zero, depending on what kind of architechture you're trying to cram them into. 8) Segments are coming to Unix. See either MACH or the Karels&McKusick paper on the new BSD virtual memory system.