[net.micro] paging and segments

LINDSAY@tl-20b.arpa (01/09/86)

>> 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
-------

kds@intelca.UUCP (Ken Shoemaker) (01/14/86)

> >> 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
> -------

How about, if you have both segments and pages, you have a piece of hardware
out there that collects your pages together, as opposed to having to keep
track of that in software.  In this way, you could allow both mechanisms
to do what they do best, i.e., segments for moving arbitrary sized user
memory blocks around, and paging for controlling your virtual memory system.
Note that it certainly is possible to use paging alone to do the same thing.
It merely is more of a programming chore, and, at least to my simple mind,
requires more work by the CPU every time you come around messing with
page tables.  BTW, the 386 does have multi-level page tables, and you
certainly can use only paging to manage your memory, ala a completely
linear 32-bit machine if you so choose.
-- 
remember, if you do it yourself, sooner or later you'll need a bigger hammer

Ken Shoemaker, Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds
	
---the above views are personal.