Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!johnl
From: johnl@ima.ima.isc.com (John R. Levine)
Newsgroups: comp.arch
Subject: Re: 386/486 Virtual Memory Question...
Summary: still botched
Message-ID: <4067@ima.ima.isc.com>
Date: 14 Jun 89 19:53:31 GMT
References: <243@mipos3.intel.com> <4056@ima.ima.isc.com> <55957@linus.UUCP>
Reply-To: johnl@ima.UUCP (John R. Levine)
Organization: Segue Software, Inc.
Lines: 58

In article <55957@linus.UUCP> you write:
>In article <4056@ima.ima.isc.com> johnl@ima.UUCP (John R. Levine) writes:
>>Unfortunately, ... the 386's segmentation is considerably less
>>useful...  
>...  I suppose that if you could only leave two
>gigabytes between them, there wouldn't be enough room for them to grow.

Of course you can do that, and indeed that's exactly what real systems do,
but it's a hack forced on you by the poor implementation of the chip's
addressing architecture.

>>In theory you could have a larger total address space and play
>>games with mapping segments in and out, but that puts strange limits on
>>applications as to which segments they can reference at the same time, so in
>>reality the limit translates to 2^32 total addresses per process. 
>>
>The "games" are no stranger than mapping virtual pages into and out of
>real memory; in fact, the two are done exactly the same way.  Your "in
>reality" should read "when you don't need to or want to use the chip's
>segmentation facilities."  Note that there are NO limitations
>on the applications; all this is invisible to them.

Actually, the games are considerably stranger than mapping virtual pages in
and out, and there are real limitations. When you map pages, every page is the
same size and is tiny compared to the size of the address space. When you map
segments, they're all different sizes and each one is potentially as big as
the full address space. Assume you have two sparse segments, each slightly
bigger than 2GB, and you do a MOVS or something from one to the other. The
system has to map in both segments at the same time, but it can't because the
linear address space isn't big enough. This is a real problem, and the only
way I know of to ensure that programs don't die from address space starvation
is to limit the total addressable to less than 4GB. As noted by another
poster, the cost of mapping segments is also very high -- any time you change
a page table you have to flush the entire TLB.

Had Intel made the page tables per-segment rather than per-process your
comments would be true, but for some reason, they didn't. I suspect that
paging was shoved into the 386 rather late in the design.

>>Unix systems map all segments to the same place and just use the paging.
>>
>I'm happy for you that UNIX is sufficiently primitive that you can leave
>such a powerful facility unused, although I'm not sure you can do a
>secure UNIX with that limitation.  I suggest you look into doing the coding
>to use full segmentation; it'll make the higher-level code much simpler.

Lots of us have looked into segmented Unix, and 286 Unix implementations work
that way. It's not very satisfactory. One problem is that there seems to be no
programming language that matches the 386's 48-bit pointer semantics very
well. People have added near and far pointers to C, but it is a widely reviled
hack and in practice makes code more complicated, not simpler. The other is
that there is a dreadful performance hit from using segments; dereferencing an
in-segment pointer takes 4 cycles while dereferencing a 48-bit pointer takes
22 or 25.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869
{ bbn | spdcc | decvax | harvard | yale }!ima!johnl, Levine@YALE.something
Massachusetts has 64 licensed drivers who are over 100 years old.  -The Globe