Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!usc!skat.usc.edu!blarson
From: blarson@skat.usc.edu (Bob Larson)
Newsgroups: comp.arch
Subject: Re: unconventional architectures
Message-ID: <17134@usc.edu>
Date: 10 May 89 00:41:46 GMT
References: <112@centaure.UUCP> <422@unicads.UUCP> <11579@cgl.ucsf.EDU> <89May6.165030edt.10782@ephemeral.ai.toronto.edu> <1989May6.234007.23517@utzoo.uucp> <89May7.001514edt.39763@neat.ai.toronto.edu> <40284@think.UUCP> <13688@watdragon.waterloo.edu>
Sender: news@usc.edu
Reply-To: blarson@skat.usc.edu (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 25

In article <13688@watdragon.waterloo.edu> tbray@watsol.waterloo.edu (Tim Bray) writes:

>Hear ye!  Segments are evil.  If my usable address space is N, it is a priori 
>*wrong* to assume that I won't mind dealing with segments of any size < N.

Segments are NOT evil, you just havn't seen an implmentation of them you like.
For a segmented pointer format to be used for the next decade or so I would
propose:

bit offset from segment base: 64 bits
segment number: 32 bits
protection ring: 16 bits
misc flags: 16 bits
(includes info like non-snapped pointer for dynamic linking, etc.)


If the offset field of the pointer is big enough to address all your
virtual address space, segmentation is NOT a limit.  (On the other hand,
poorly designed segments (intel) are horid.)

-- 
Bob Larson	Arpa:	blarson@skat.usc.edu
Uucp: {uunet,cit-vax}!usc!skat!blarson
Prime mailing list:	info-prime-request%ais1@ecla.usc.edu
			usc!ais1!info-prime-request