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)