Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!boulder!unicads!les
From: les@unicads.UUCP (Les Milash)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation (
Message-ID: <642@unicads.UUCP>
Date: 14 Sep 89 15:29:38 GMT
References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM>
Reply-To: les@unicads.UUCP (Les Milash)
Organization: Unicad  Boulder, CO
Lines: 28

In article <34701@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes:
>>In article <261500010@S34.Prime.COM> BEAR@S34.Prime.COM writes:
>>*really* discussing is whether or
>>not MEMORY MAPPED I/O is a good thing. The concensus seems to be that it
>>should be avoided

>OK, I'll bite. What are the characteristics of memory mapped I/O that enable
>it to avoid the problems we are talking about?

i'll summarize (and i'm sure y'all will correct me if i'm wrong:-)
memory mapped i/o has to be "memory-like" since processors will often assume
that stuff in the "memory space" is memory-like, even to the point of calling
its "memory space" virtual and translating to physical.

memory-like devices have the property that if you inquire their value multiple
times all you get is their value (multiple times).  restart is not a problem.
fifos are not memory-like; reading them causes all kinds of side effects
in them including that their value gets forgotten you forgot it (specifically 
they are channel-like (in CSP vernacular))

another lesson recently learned from this newsgroup is that i/o devices that
you can write but not read (like cmd registers to some XXX controller chip)
also are a pain in the ass (but not in the virtual ass; it's the driver 
writer's ass that gets bit).

right?

Les Milash