Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!apple!sun-barr!texsun!texbell!nuchat!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation (
Message-ID: <6283@ficc.uu.net>
Date: 25 Sep 89 11:53:42 GMT
References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <5876@tolerant.UUCP>
Organization: Xenix Support, FICC
Lines: 21

In article <5876@tolerant.UUCP>, bruce@tolerant.UUCP (Bruce Hochuli) writes:
> Back to the larger issue, I still don't understand how re-issuing
> an instruction could avoid having to face [problems with memory mapped
> I/O].

What is the characteristic that makes "I/O mapped" I/O (that is, I/O that
uses special instructions to access the I/O address space) safe? The
characteristic is that the instruction can not fault in such a way that
an I/O operation is performed twice. That is, "I/O mapped" instructions
are inherently load/store.

What is the characteristic that makes memory mapped I/O dangerous? That
if a memory-memory instruction with an I/O device at one end faults, the
I/O operation can be duplicated. The simple solution is... don't perform
memory-memory instructions on I/O. Fairly easy in CISC, and simple in most
RISC architectures... they don't have memory-memory operations.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"That is not the Usenet tradition, but it's a solidly-entrenched            U
 delusion now." -- brian@ucsd.Edu (Brian Kantor)