Path: utzoo!attcan!uunet!ginosko!brutus.cs.uiuc.edu!apple!mips!wyse!stevew
From: stevew@wyse.wyse.com (Steve Wilson xttemp dept303)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation (
Message-ID: <2451@wyse.wyse.com>
Date: 27 Sep 89 22:58:32 GMT
References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <5876@tolerant.UUCP> <6283@ficc.uu.net>
Sender: news@wyse.wyse.com
Reply-To: stevew@wyse.UUCP (Steve Wilson xttemp dept303)
Organization: Wyse Technology
Lines: 39

In article <6283@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>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,

Can't agree with your statement about it being fairly easy to avoid doing
memory operations on memory-mapped I/O using  CISCS.  There are several
CISCs(the 68k and 32K come immediately to mind) that don't have I/O 
instructions of any sort, therefore you have to map the I/O registers
into the machine's memory space.  Assume you've got a FIFO type device
such as a USART.  Any read of the data register will be destructive, i.e.
the memory location value will change as a function of the arriving characters
in the USART's FIFO.  The only way that a 68k or 32k can talk to this 
device is via the micro's memory space.  If the micro is designed to 
"instruction restart" you have to guarantee that the select NEVER got
out to the USART.  This tends to get in the way of building zero 
wait-state hardware ;-)   I think this is the type of problem Bruce
is talking about(Hi Bruce).

Steve Wilson
Consultant at large
Currently serving time at Wyse Technology

Standard Disclaimer - These are my opinions, not those of my employer's.