Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!philmtl!philabs!linus!munck
From: munck@linus.UUCP (Robert Munck)
Newsgroups: comp.arch
Subject: Re: 386/486 Virtual Memory Question...
Message-ID: <55563@linus.UUCP>
Date: 8 Jun 89 14:34:40 GMT
References: <MYX2SzW00XoF42d1lf@andrew.cmu.edu>
Reply-To: munck@faron.UUCP (Robert Munck)
Organization: The MITRE Corporation, Bedford MA
Lines: 54

In article <MYX2SzW00XoF42d1lf@andrew.cmu.edu> hs0l+@andrew.cmu.edu (Hugh Brinkley Sprunt) writes:
>
>The 386 and 486 architectures claim a virtual address space size of
>2^46 bytes.  The virtual address is formed from a 14 bit selector
>and a 32 bit offset.  What does this really mean?  Currently we have
>two interpretations:
>
>	a) This scheme gives us 2^14 different ways to map into
>	   the same 32 bit address space.
>
>	b) This scheme gives us 2^14 independent address spaces
>	   of 2^32 bytes each.  In other words, the virtual memory
>	   scheme consists of as many as 2^14 segments of 2^32
>	   bytes each.
>

No, both are wrong, though the second sentence of (b) is true.  Each
task has a (single) *two-dimensional* address space of 2^14 segments,
each of which can be as large as 2^32 bytes (2^13 segments shared with
all other tasks - Global Descriptor Table, 2^13 potentially private -
Local Descriptor Table).

Also, (a) is partially true.  All segments currently in use (ie with
their descriptors in segment registers or flagged "Present") must map
into a single, potentially private "linear address space" of 2^32 bytes. 
To allow use of the whole 2^46 address space, the OS must field segment
exceptions and manipulate the task's page directory and page tables to
change the mapping of the linear address space.

In addition to the global 2^13 segment descriptors, tasks can share
directories (second-level page tables) or individual page tables or
individual pages.  Segments can overlap each other in the linear address
space in arbitrary ways.  The number of design alternatives is immense.

For example, in the OS I'm building, I define a "process" as a set of
tasks sharing a single directory (therefore sharing a single linear
address space) and sharing a single LDT.  1024 of the LDT entries are
mapped 1:1 to entries in the directory and to individual page tables,
therefore defining 1024 4Mbyte segments.  Each of these can be connected
to a disk file of 1..1024 page images.  To run a program, connect one of
the segments to a file of executable code and set the CS (Code Segment)
register to it and the IP (Instruction Pointer) register to the offset
of the entry point.  Instruction fetch will cause a page fault, the OS
brings in the page, and the program is off and running.  To do "disk
I/O," connect the data file to another segment and access it with move
instructions.  (Consequences: files are 4Mbytes max and a program can
have no more than 1023 of them in use at once; not serious limits.)

(BTW, my OS implements B3 security, is written in Pascal, and will be
Public Domain when finished.)

                            -- Bob Munck, MITRE-Washington
                            -- munck@mitre.org, ...!linus!munck
                            -- 703/883-6688