Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!calgary!ctycal!ingoldsb
From: ingoldsb@ctycal.COM (Terry Ingoldsby)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation (
Summary: I/O with memory mapped devices
Message-ID: <477@ctycal.UUCP>
Date: 28 Sep 89 18:40:36 GMT
References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <2451@wyse.wyse.com>
Organization: The City of Calgary, Ab
Lines: 51

In article <2451@wyse.wyse.com>, stevew@wyse.wyse.com (Steve Wilson xttemp dept303) writes:
> 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
> 
> 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

I think what is being suggested is a method of preserving the philosophy
of I/O mapped instructions using a processor that only has memory mapped
I/O.  Generally, what you are trying to avoid is a page fault (or some
other sort of interrupt/trap/bus error that would happen part way through
an instruction, thus causing it to wait for the fault to clear, and then
re-execute the entire instruction.  Suppose, for example, you wanted to
read a data byte from the data register (which is mapped to address addr1)
of a serial device.  If you performed a CISCy, memory based instruction like:
    MOVM      addr1,addr2    (ie Move data found at location addr1 to addr2)
then if addr1 and addr2 are not in the same page, a page fault may occur.
Since the processor might not know this until it had accessed addr1 (and
was trying to access addr2) then execution would pause until the fault
had been corrected (ie. the page brought into memory) and then the whole
instruction would repeat.  The next value would be read from the peripheral
data register (losing the previous value).

As an alternative, do the following:
    MOV       addr1,R1      (ie Move data found at addr1 into register R1)
    STO       R1,addr2      (store register contents in addr2)
Even if the fault occurs during the read of addr1 (a bit odd since
peripheral memory locations are usually non-pageable) then the access will
still only occur once.  If the page fault occurs during the store then
we similarly don't care since addr2 will also only be accessed once (in my
example its just memory but could conceivably be another peripheral).

Sorry to ramble on (I usually prefer to listen), but I thought there was
some abiguity in the discussion.

-- 
  Terry Ingoldsby                       ctycal!ingoldsb@calgary.UUCP
  Land Information Systems                           or
  The City of Calgary         ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb