🚀 go-pugleaf

In article <?> kquick@simpact.com (Kevin Quick, Simpact Assoc., Inc.) writes:
}In article <?>, hascall@atanasoff.cs.iastate.edu (John Hascall) writes:
}>     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??

}The above instruction examples do show the possible problems involved in
}restarting vs continuing instructions when accessing device registers, but
}the third and fourth instructions above are usually protected (under VAX/VMS)
}in another fashion, namely the Interrupt Priority Level (IPL).

  Mostly, raising IPL protects you from critical section problems (talking
  uni-processor here).  Section 6.2 of "Writing a Device Driver for VAX/VMS"
  states (item 7):

       To access I/O space, use only the following instructions.  These
       instructions cannot be interrupted unless they use autoincrement-
       defferred addressing mode or any of the displacement-deferred modes
       when specifying an operand.
 
}In relating this to the third and fourth instructions presented by Mr. Hascall,
}it is observed that a VAX/VMS page fault will occur at IPL 2, and is therefore
}prevented when accessing device registers at IPL 20.

       Page faults are not allowed above IPL 2, not for really architectural
 reasons, but because of the critical section problem and since VMS does
 process scheduling at IPL 3 (there may be not be a process context in
 which to make the page valid).
 
       Anyway, the use of VAX instructions was purely for my own convenience.
 My point was, (as was restated by Mr. Quick), regardless of instructions
 available most/all device drivers only need access (memory mapped) device
 registers in a simple fashion.  Thus, I don't think memory mapped I/O is
 somehow less flexible than having specific I/O instructions as was suggested
 earlier even if certain instructions and/or addressing modes have to be
 prohibited.

John Hascall