80x86 summary, comparing to Multics.
Bernard S Greenberg
me. Other '86 victims are invited to comment on it.
Bernie
==========
The 80x86 and Multics
Bernard S. Greenberg (b...@world.std.com)
The INTEL 80x86 series employs segmentation to compensate for
registers too short to contain a useful address; the result has
universally been perceived as nuisance rather than a boon. While the
higher processors in the series begin to compromise with Multics-like
"useful" segmentation, programmer experience with the lower
processors has created a backlash against segmentation which seems to
have set the future course of 80x86 hardware and software.
The 8086, the "common core" processor of the series, has a 1 MB (2^20)
physical address space, and 16-bit registers (addressing 2^16 = 65535
bytes) with which to address it. Addresses are indeed formed in a
Multics-like segment/offset fashion from segment numbers in dedicated,
user-visible registers (DS, ES, SS (stack)) and a procedure pointer
register (CS), but are resolved not through a descriptor segment/table,
but by merely shifting the segment number four bits and adding it to the
offset (byte number). This provides addressability for 2^16+4 = 2^20
words, but the relatively small segment size still remains a problem, and
none of the advantages of segmentation when "done right" (independent
segment growth, independent paging, virtual files, protection firewalls,
etc.) are gained. As there are no segment descriptors, there are no
segment faults, access faults, bounds faults, or the like: segment
addressing always wraps around.
The 80286 goes quite a ways further; while by default operating almost
exactly as the 8086 described above (now called "real mode"), when thrown
into "protected mode", a true "descriptor segment" (actually, two of
them, intended for per-process and global use, selected by one bit of the
segment number, which is in this context called a "selector") comes into
use: the segment descriptors decidedly resemble those of Multics,
including access rights, ring numbers (0-3) (but just one, i.e., no
brackets), and bounds. The physical address space is 16 MB (2^24), and
segment descriptors can point anywhere within it; there is no paging.
The final memory address is the sum of the "offset" and the base in the
descriptor. Ring validation is computed from bits in the segment number
(only the top 14 of 16 bits (including global/local) really select a
descriptor, the "effective ring number" takes two bits here), the current
procedure ring register, and bits in the segment descriptor. The
"supervisor" is expected to run in ring 0 and implement a traditional
supervisor/user protection/privilege regime. As in other segmented, but
not paged, operating systems (e.g., the Burroughs 5500 mentioned above),
periodic memory garbage collection and compaction becomes an issue, and
segment-by-segment swapping and replacement via missing-segment fault are
employed. Although the firewall and protection aspects of segmentation
are now gained, the small segment size remains a problem and dynamic
segment growth is difficult for the operating system. There are also
inter-ring gates (a Multics concept) and other frills.
While on one hand, the 80386 (and '486) grants a belated acknowledgement
of the true advantages of segmentation, with the other hand it
capitulates to its detractors. In "real mode" again identical to the
8086, in "protected mode" a descriptor architecture more or less
identical to that of the 80286 above pertains, with the addressible
physical address space expanded to 4GB (2^32). But when global (not
per-segment!) paging is enabled, the 32-bit (4GB) "linear address", as
the final result of the computation just described is known, is
implemented as a 4GB demand-paged virtual address space, pages being 4KB
(modulo the 8/9 bit distinction, the same size as Multics'!). As a
million PTW's are necessitated by this scheme, it is subdivided into 1K
of 4MB (size of four maximal Multics segments) chunks through a
second-level page table of 1K entries, each of which may be faulted (and
access-controlled at the page level) as well. Segments can describe (be
"mapped into") any section of the linear address space from a single byte
in length to the full 4 gigabytes (with two granularities). As usual,
paging is wholly invisible to the user.
Bits in each 80386 segment descriptor enable "32-bit mode", by which most
visible machine registers and/or data offsets referenced within such
segments are expanded to 32 bits, for the first time time opening the
possibility of overcoming the largest problem with 80x86 segmentation.
However, the trend in recent Microsoft operating systems is to map one
large segment (actually two identical except for access rights) on the
entire 4GB address space (with the operating system controlling access
rights via PTW's). The intent and the effect are to nullify and
"overcome" segmentation, as per the backlash described above: the result,
called "flat addressing", is now considered a feature, except by
ex-Multicians.
Note that with paging, segments do -not- have their own page tables, nor
are their boundaries even constrained to coincide with page boundaries,
although it is possible to "line up" 4MB "chunks" of the linear address
space with selectors on a one-to-one basis, making the second-level page
table an extension of the descriptor table(s), and effecting Multics-like
segmentation (the Microsoft operating systems do not do this). This
does, however, impose a limit of 1K on the number of segments, which is
unquestionably too small. The "large paged address space" trades and
compromises "compaction" and "freedom from segmentation" against the
benefits of segmentation gained with this ersatz-Multics scheme. Using
the latter to implement Multics-like "virtual files" is in fact an
available "mode" of opening files in Microsoft's Windows/NT, but not the
basis of the entire software architecture as in Multics.
The 80386 also implements a hardware multitasking architecture with
a complex hardware-maintained state-vector, and an intriguing "virtual
8086 mode", which reverts to the 8086 method of address formation,
while resolving the resulting 20-bit (actually, occasionally-21-bit)
address into the 4GB address space (unfortunately, always at its start).
This allows the running of multiple, mutually inter-protected
8086-like machine images under the same supervisor, a capacity
fully exploited by recent Microsoft operating systems.
9-12 September 1994
=========================