🚀 go-pugleaf

In article <642@unicads.UUCP> les@unicads.UUCP (Les Milash) writes:
: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))
:
Stuff deleted!

Seems to me that this conversation just took a weird turn. The issue here
is not memory mapped vs. I/O mapped, but just what devices are we dealing
with.

One example, if I have an Intel 8254 out there; I have to make my
accesses in a very particular order. I issue a command (access 1)
and I read/write my data (access 2). If I reissue access 1, I will
have a very confused counter/timer out there. Note that this has 
nothing whatever to do with memory or I/O mapping. The same 
example holds true for lots of devices that a designer might
hang on a bus.

Back to the larger issue, I still don't understand how re-issuing
an instruction could avoid having to face this issue.