Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!decwrl!pyramid!hplabs!felix!peregrine!mike
From: mike@peregrine.UUCP (Mike Wexler)
Newsgroups: comp.sys.intel,comp.lang.c
Subject: Re: segments and Unix
Message-ID: <1219@peregrine.UUCP>
Date: Mon, 24-Nov-86 20:10:11 EST
Article-I.D.: peregrin.1219
Posted: Mon Nov 24 20:10:11 1986
Date-Received: Wed, 26-Nov-86 20:33:37 EST
References: <13802@amdcad.UUCP> <9400@sun.uucp> <260@mipos3.UUCP>
Organization: Peregrine Systems, Inc., Irvine, CA
Lines: 20
Xref: mnetor comp.sys.intel:64 comp.lang.c:175

Reply-To: mike@peregrine.UUCP (Mike Wexler)
Organization: Peregrine Systems, Inc., Irvine, CA

In article <260@mipos3.UUCP> kds@mipos3.UUCP (Ken Shoemaker ~) writes:
->I'm sorry, but I have to take exception to some of the points raised here:
->In article <9400@sun.uucp> david@sun.uUCp (David DiGiacomo) writes:
->>No, for four reasons:
->> - It is very expensive to expand pointers to hold a reasonably large 
->>   (16 bit?) segment number field.
->very expensive?  They are already at least 32-bits wide!  Besides, I
->thought that the whole idea of the 32-bit processors was that you got
->to talk to lots of memory...
The point is to handle segments you would want to have 48 bit points:
a 16 bit segment number and a 32 bit offset within the segment.  Otherwise,
you would be limiting how big individual objects could be.  The other problem
is you might want to have >65536 objects.
-- 
Mike Wexler
(trwrb|scgvaxd)!felix!peregrine!mike
(714)855-3923