Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!bywater!scifi!watson!gary.watson.ibm.com!oasis
From: oasis@gary.watson.ibm.com (GA.Hoffman)
Newsgroups: comp.arch
Subject: Re: Segmented Architectures
Message-ID: <1991Apr05.161615.16869@watson.ibm.com>
Date: 5 Apr 91 16:16:15 GMT
References: <1991Apr04.234928.8637@iecc.cambridge.ma.us>
Sender: @watson.ibm.com
Reply-To: oasis@watson.ibm.com
Organization: IBM Research, RISC Systems
Lines: 17

I've worked extensively on the IBM RT and RS/6000 .. we consider both to
be segmented machines.  Native support by compilers only uses a few 
segments -- mapping text, bss, etc onto segments 0,1,2,3.  Thru shmat(),
segment registers may be loaded for use of the entire 32-bit effective-
address space.  These segments, supported by hardware segment-registers,
provide one-cycle loads and stores with hardware protections and capabilities.  Protections and capabilities are very useful and difficult
to implement without something simple like segments ... our segments are
selected by the high-order 4-bits of an effective-address.  Having protections and capabilities that could start on arbitrary pages and go to arbitrary sizes would require something like a CAM; this is very expensive in silicon.

The only serious complaint I've ever had about how we do segments, is that the segments are too small and there aren't enough of them active concurrently
Our segments are 256M-bytes, and there are only about 12 segment-registers
available.  These numbers are too small for all the objects that Mach and
other programs would like to have active simultaneously.  So there is overhead for changing segment-registers, like shmat() and shmdt(), but the
overhead has not proven unbearable.
 
-- 
g