Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!talcott!panda!genrad!decvax!decwrl!sun!idi!intelca!glen
From: glen@intelca.UUCP (Glen Shires)
Newsgroups: net.micro
Subject: Re: Re: 386 Family Products
Message-ID: <170@intelca.UUCP>
Date: Mon, 6-Jan-86 16:28:59 EST
Article-I.D.: intelca.170
Posted: Mon Jan  6 16:28:59 1986
Date-Received: Wed, 8-Jan-86 20:28:45 EST
References: <129@intelca> <4400130@uiucdcsb> <6185@utzoo.UUCP> <6246@utzoo.UUCP>, <467@ihlpl.UUCP> <6260@utzoo.UUCP>
Organization: Intel, Santa Clara, Ca.
Lines: 27

> > > ... irrelevant to the point I was making:  that the 386's
> > > segments are largely useless, and do not constitute a useful feature.
> > 
> > 386 segments provide a useful way to access data files as a byte-addressable
> > array instead of as a series of records which must be seeked, getted and putted.
> 
> You can do that perfectly well with a paging machine, given a decent MMU
> design; you don't need the silly segments.  That's pretty much how shared-
> text binaries work on 4BSD, and (as I recall) 4.2 was originally planned
> to have more general file-into-address-space mapping primitives as well.
> On a paged machine.
> -- 
I agree completely:
You just write code that deals with pages, keeping track of which pieces
of code are located in which sets of pages, and their attributes
(read/write/present/dirty/etc).  Essentially maintaining a data structure that
maps logical code chunks into the hardware pages and keeping track what's where.

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.
O O     Usenet: {ucbvax!amd,pur-ee,hplabs}!intelca!glen
 >      ARPA:   "amd!intelca!glen"@BERKELEY
\-/    --- stay mellow