Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.arch,net.micro.16k,net.micro.68k
Subject: Re: 24 bit vs. 32 bit address space
Message-ID: <5543@utzoo.UUCP>
Date: Thu, 25-Apr-85 11:56:11 EST
Article-I.D.: utzoo.5543
Posted: Thu Apr 25 11:56:11 1985
Date-Received: Thu, 25-Apr-85 11:56:11 EST
References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP>
Organization: U of Toronto Zoology
Lines: 48

> > The point is, you can map files into a process's address space on
> > a sufficiently-cooperative machine (I doubt that the 80*86
> > qualifies), but it is very hard to make pipes and devices act
> > like files if you do this.
> 
> Why?  If you make pipes do this, then what you have is equivalent to a
> shared memory segment.  The major distinction between pipes and shared
> memory in this regard is that pipes are unidirectional and force sequential
> access to the data (this is, in fact, a problem with a lot of the current
> interprocess communication schemes).  If you map the pipe into the address
> space on the output side of one process, and into the address space on the
> input side of another process, then you have a shared memory segment
> (except that you might make it write-only on the output side and read-only
> on the input side in order to make it more pipe-like, to restrict the flow
> of data to one direction).

Precisely, what you have is a shared memory segment, requiring (potentially)
many megabytes of buffering for data that is in fact being read only in
a completely sequential way.  Besides, how does the receiving process know
when the next lump of data has been deposited at the end of the segment?
Spin in a loop waiting for the off-the-end-of-the-segment addressing faults
to stop?  You end up with a substantial amount of specialized machinery
that is relevant *only* to pipes, defeating the crucial notion that pipes
"look like" normal files and programs don't need special preparations
to work from a pipe.

> Making devices be mapped into a process's address space actually would solve
> many problems.  It is already done for some sequential devices, such as
> serial ports, on "memory-mapped I/O" machines.

Again, sure, you can do it... but those serial ports do *NOT* look like
files to the software.  Once again, programs have to *know* what sort of
thing they are talking to:  not only that they are talking to a serial
port, mind you, but exactly what the hardware looks like!  This is the
exact reverse of device-independence, which is what the "everything's
a stream of bytes" I/O model gets you.

> ...And of course, primary memory is a random access device
> that is almost always mapped into the address space (except on micromachines
> such as PE's 3200 series, where you address it in much the way you address
> a disk, by writing the address you want to access, then waiting for the
> data to become available).

Actually, that is the way main memory works on most machines, at the
microprogramming level.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry