Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!lll-crg!seismo!brl-tgr!tgr!LINDSAY@tl-20b.arpa
From: LINDSAY@tl-20b.arpa
Newsgroups: net.micro
Subject: RE: paging and segments (i386 complaint department)
Message-ID: <1400@brl-tgr.ARPA>
Date: Thu, 9-Jan-86 14:30:20 EST
Article-I.D.: brl-tgr.1400
Posted: Thu Jan  9 14:30:20 1986
Date-Received: Mon, 13-Jan-86 04:39:58 EST
Sender: news@brl-tgr.ARPA
Lines: 25

>> Gee whiz...That's exactly what segmentation on top of paging is.
>> The only difference is that you prefer to do it in software, while the
>> 386 lets you to do it in either hardware or software.
>> Glen Shires, Intel, Santa Clara, Ca.

This is incorrect. There is surprisingly little difference between having
N segments (each paged), and having a paged memory, with some groups of pages
treated as segments. In both cases, there has to be a data structure which
explains what is going on. In both cases, the structure is created by kernel
calls. In both cases, the hardware updates such things as "dirty bits". In
both cases, "not present" interrupts invoke software which updates the data
structure after performing disk I/O.

Further, the data structures are of similar size and complexity. Note that
paged systems typically use multilevel page tables, so that they don't have
to keep entries discribing gigabyte upon gigabyte of unused address space.
It's called "segmenting" and it works fine.

There are a few areas that ARE worth talking about:
 - granularity ( can you have an 80 byte segment ?)
 - sharing and domains ( can multiprogramming work as some OS designer wants ?)
 - future growth ( is 4 gigabytes really enough ?)

Don Lindsay
-------