Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!atanasoff!hascall From: hascall@atanasoff.cs.iastate.edu (John Hascall) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation ( Message-ID: <1516@atanasoff.cs.iastate.edu> Date: 15 Sep 89 00:26:41 GMT References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <642@unicads.UUCP> Reply-To: hascall@atanasoff.cs.iastate.edu.UUCP (John Hascall) Organization: Iowa State Univ. Computation Center Lines: 42 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