🚀 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
 
}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))
 

    I guess I fail to see the problem.  I agree that for many I/O devices
    re-reading a device-register is a bad thing.  What I don't see is how
    this can happen except when:

	 a) you have an instruction (or instr. set) which is restarted
               *and*
         b) you have an instruction that reads from two (or more)
	    operands (and the I/O location is not the last one read?).

    Are there machines which can get a page-fault acessing a memory-mapped
    I/O device register location?? (surely not!)

    Examples using the VAX instruction set (write operands are rightmost):

         MOVW   IO_DEV_CSR,R0         ; no problem: no page faults in I/O space
				      ;  (even if MOVW was a restarted instr)
	 SUBW3  IO_DEV_CSR,(R2)+,R3   ; no problem: SUBW3 is continued
         SUBW3  IO_DEV_CSR,@(R2)+,R3  ; trouble: @(R2)+ can cause page fault
	 SUBW3  @(R2)+,IO_DEV_CSR,R3  ; can you get away with this because the
				      ; I/O operand is read last?? 

    I just can't see where you would use such wierd instructions in a
    device driver when accessing memory-mapped I/O registers (even in a
    multiple-memory-accesses-per-instruction machine like the VAX).

John Hascall
Systems Group
ISU Comp Center