Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site baylor.UUCP
Path: utzoo!linus!decvax!genrad!panda!talcott!harvard!seismo!rochester!rocksanne!sunybcs!kitty!baylor!peter
From: peter@baylor.UUCP (Peter da Silva)
Newsgroups: net.micro
Subject: Re: Re: 386 Family Products
Message-ID: <608@baylor.UUCP>
Date: Wed, 1-Jan-86 13:08:17 EST
Article-I.D.: baylor.608
Posted: Wed Jan  1 13:08:17 1986
Date-Received: Sat, 4-Jan-86 07:07:41 EST
References: <129@intelca> <4400130@uiucdcsb> <6185@utzoo.UUCP> <6246@utzoo.UUCP> <467@ihlpl.UUCP>
Organization: The Power Elite, Houston, TX
Lines: 21

> > > On the 386, "small model" (which of course does not exist per se) is
> > > 4 Gigabytes.
> > 
> > Quite true, but 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.

Would you care to explain what memory addressing has to do with accessing
files. Perhaps you are referring to a possible mapping of the file directly
into the process' address space... something which is possible in any hardware
architecture that supports VM (whether or not the software supports it, of
course). This is, of course, merely a way of putting the seeking, reading,
and writing off for a little while. It may actually be useful, though it sounds
a little inefficient. In any case it's hardly a capability restricted to
segmented architectures. In fact it has nothing to do with segmenting... it's
an attribute of VM.
-- 
-- Peter da Silva
-- UUCP: ...!shell!{baylor,graffiti}!peter; MCI: PDASILVA; CIS: 70216,1076