VM on a 286?
Charles Hedrick
hedrick at athos.rutgers.edu
Mon Sep 12 17:38:46 AEST 1988
Yes, the 286 can do virtual memory. All the mechanism is there,
however if I'm reading the documentation correctly, it's not quite
usable. The problem is that the designers couldn't decide whether
they were doing virtual memory or segments, and managed to make
something that isn't terribly useful as either. As Multics proved,
segments are a very cute idea. With an OS that has all files showing
up in memory, sharable libraries, etc., the segments are useful for
organizing the resulting immense virtual memory. However they aren't
useful for doing VM. In order to do VM, you need pages whose
addresses are contiguous, and which are moderate in size. That is,
you want the first page to be 0-1fff, the next to be 2000-3fff, etc.
The program should not be aware of the page boundaries. The OS should
page in those pages that are needed. Unfortunately, the 286 segments
are not contiguous, because the bits that control access rights are in
the wrong place: segment number|magic bits|offset in segment. So
addresses jump from 0000ffff to 0008ffff instead of 0001ffff, because
the 00070000 bits are the magic bits. This means that the segments
aren't invisible to the software. Thus you have to think of the
address space as a discrete collection of segments, rather than pages.
In fact you could "page" the segments. That is, you could keep
segments in backing store until they are needed. However doing so
with the 286 would present you would an unenviable choice: either
you'd have to use only a few K of each segment (meaning that you
couldn't have any subroutine or data structure bigger than say 4K), or
you end up having to page in and out 64K chunks. With typical
programs of a few hundred K and slow microcomputer disks, in my
opinion 64K chunks are too large to get reasonable results from
paging.
If you're going to go for segments (which as I said, I think is a neat
idea in theory), you really need two levels of memory mapping. At the
top level, you would have segments that are very large, say with 32
bits of address space. For each segment you'd have a separate page
table, with pages of a few K, and contiguous address space. (I think
that's what the 386 does.) The 286 tried to make a single level of
segments do both, and ended up with segments that were too small to
allow reasonable 32-bit programs, but too large to allow them to be
used as pages. The 8086 and 8088 were simply out of date compared to
the 68000. The 286 was worse: it was ill-conceived. Intel should
have used the silicon to do a simple page table scheme instead of the
segments. Or at least put the magic bits at the high-order end of
the address, so addresses would be contiguous.
More information about the Comp.unix.microport
mailing list