Newsgroups: comp.arch
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers)
Message-ID: <1991Apr1.173552.15628@Think.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <1991Mar27.172325.10800@sj.nec.com> <00670208556@elgamy.RAIDERNET.COM> <1991Apr1.045051.3220@grebyn.com>
Date: Mon, 1 Apr 91 17:35:52 GMT

In article <1991Apr1.045051.3220@grebyn.com> ckp@grebyn.com (Checkpoint Technologies) writes:
>Suppose you took a machine with a very large pointer; 32 bits will do
>for arguments' sake, but you could imagine this with 48 or 64 if you
>like.  Then let's say the operating system permits an application to
>have a sparse virtual address space.  Then applications could choose
>some number of upper address bits and designate those as "segment
>numbers", and the rest of the bits as "offset".
>
>Now, what significant differences exist between this and a "real"
>segmented machine?  I can't think of any offhand...

My experience with "real" segmented machines is limited to Multics on
Honeywell Level 68 and DPS8 hardware.  In this architecture and OS,
segments are used to manage memory sharing and file mapping.

In the case of shared memory, the entry in the segment table
for each process using a shared segment would point to the same segment
descriptor in the kernel, and the segment descriptor contains the page
table entries.  This way, when the segment grows or shrinks, all the
processes see the change; if this were done using per-process page tables,
there would have to be a routine that goes around updating all the
processes' page tables (and what happens if one of the processes didn't
leave enough room after the shared memory?).  The use of real segments in
memory management serves the same purpose as inodes in the file system:
processes are like directories, segment descriptors are like inode numbers,
and page tables are like inodes.

The relevance to file mapping is that protection modes are implemented at
the segment level, rather than at the page level.  A process either has
read-write, read-only, or no access to all of a segment.  Since segment
tables tend to be smaller than page tables, this probably reduces the
amount of silicon needed to implement memory protection.  Since Multics has
a fairly elaborate memory protection system (in addition to the
aforementioned read-only vs read-write, there are also protection rings),
this was probably an important simplification.  Since it's likely that the
necessary protection of all of a segment will be the same, the lost
flexibility can be negligable (although Multics did need to special-case
gate segments, which an outer-ring caller could only execute by transfering
to certain offsets, in order to guarantee that the appropriate entry
sequence was executed).

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
