Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!uvaarpa!virginia!uvacs!mac
From: mac@uvacs.cs.Virginia.EDU (Alex Colvin)
Newsgroups: comp.arch
Subject: Re: Slandering Project MAC (was Slandering Intel)
Summary: GE vs Intel segments
Message-ID: <196@uvacs.cs.Virginia.EDU>
Date: 22 Jun 89 15:25:20 GMT
References: <182@mipos3.intel.com> <76700071@p.cs.uiuc.edu> <2126@yunexus.UUCP>
Organization: University of Virginia
Lines: 26

(Sorry if this has already been hacked to death.  Something is clogged in our
news feed.)

> [responding to a discussion involving Intel's idea of segmentation]
>   The only similarity between the segments (aka files) defined by
> project MAC and the segments used for address-space-extension by intel
> is in the name.  Project MAC is not, was not and never will be
> responsible for this particular misuse of the terminology.

We're talking segments in the processor address space here, not Multics
mapping into the file system.  And yes, there is a similarity.  GE 645
operands coud select from 8 segment registers, where iNtel can select from
4.  GE segments were 1^18 words long, iNtel 2^16 bytes.  Therein lies the
rub.  In the 60s, 1/4 MW was a lot, enough for almost any program.  In the
80s, 1/16 MB is not a lot, too small for many programs.  Even so, 256KW
turned out to be too small for some files.

There is a difference in the coordination of segments and pages.  GE645
segments had their own page tables. iNtel segments are offset into a global
page table.  This makes sharing small segments practical.  You might think
of them more as capability pointers.  It also means you don't have to do
TLB flushes on every context switch.

After Honeywell took over the Multics line (the H6180), their next
architecture (the H6600, DPS8) used this global page table approach.
(well, actually a Working-Space Quarter or something equally wierd).