ISee Section 3.7
7.5 DEVICE HANDLER'S CAL PROCESSOR .1 Arguments of the CAL
The first 37 (octal) words of an I/O handler must have the format described in the following pages. The CAL handler in the Monitor has been implemented to do as much of the function processing as possible. In giving control to the I/O handler, the CAL handler will have set up registers in the I/O handler with all pertinent information (arguments) of the CAL in the most accessible state, and will then transfer control to the appropriate function processor via the JMP
table in the I/O handler which begins at word 208 relative to the first location in the handler. Since CAL is not a reentrant process, CAL instructions should not be executed while at the CAL level or at a hardware interrupt level:
ISuch as, REALTP and IOBUSY.
2As a special case, the Monitor allows the MAGtape handler to do so.
7-8
WORD ~: JMS SWAP
The SWAP subroutine is in the device handler. The JMS instruction will be simulated from within the Monitor so that the SWAP routine will return to the Monitor and not to WORDI of the handler. The SWAP subroutine must execute WORDS which restores the state of the program interruptI and DBK from level ~ or 1 of the API. The presence of this routine becomes functionally necessary for type 3 (Multi-user) handlers to accomplish swapping from Background to Foreground usage. The I/O device independence of the system requires that all handlers look alike to the outside world (namely, the Monitor's CAL handler).
WORD 1:
WORD 2:
For both busy registers:
~
=
Not BusyNon-~
=
Busy/Foreground Busy Register2 /Background Busy Register2
(the CAL handler in the Monitor places the current .DAT slot number here full 18 bit value if negative.)
When the Monitor's CAL handler receives an I/O call, i t checks the validity of the .DAT slot number for this job (Foreground or Background), checking for its existence, whether or not a device has been assigned to i t , and if the appro-priate handler was loaded.
The CAL handler then checks the appropriate busy register3 and proceeds as follows:
1. If the flag indicates that the handler is already busy, the job becomes I/O bound at this level. Foreground can become I/O
bound at 4 levels, which means i t gives up control to lower levels or to the Background until the I/O operation is completed.
2. If the flag indicates not busy, i t is set to busy' and the CAL handler processes the function and passes the request on to the device handler.
IThis is a vestige from PDP-~ code.
2Must be assembled with contents =~. The Teletype handler is a special case.
3The Teletype handler is an exception.
4Actually, there is also a test on the CLOSE flag (Word 3 or 4) which is des-cribed on the next few pages. As a result, the function might not be passed on to the handler.
Note that .WAIT's and .WAITR's are completely processed by the CAL handler and
1
are not passed on to the I/O handler .
If the corresponding busy register indicates busy:
1. For .WAIT in the Foreground, control is given to a lower Foreground level or to the Background. The .WAIT command is not reexecutedj instead, the WAIT condition is recorded for the specific Foreground level in a .SCOM register. When the I/O completes, the device
handler will call the IOBUSY routine in the Monitor, which will clear the WAIT condition and prepare to resume processing at that level following the .WAIT.
2. For .WAIT in the Background, since there is no further processing that can be done, control is returned to the .WAIT.
3. For .WAITR in either the Background or Foreground, control goes to the address specified in LOC+2 (which must be above the hardware memory protect bound if in the Background) 2.
If the corresponding busy register indicates not busy, the WAIT condition has been satisfied and control is returned to LOC+2 (if .WAIT) or LOC+3 (if .WAITR).
WORD 3:
WORD 4:
For both .CLOSE registers:
/Foreground .CLOSE register3 •
/Background .CLOSE register3 •
~ = .CLOSE or .OPER not in progress
Non-~
=
.CLOSE or .OPER in progress.CLOSE and .OPER functions have a built-in WAIT condition. When the .CLOSE or .OPER is first executed, the busy register and .CLOSE register for the appro-priate job contain zero. The CAL handler in the Monitor sets the return PC so that the function will be reexecuted. The busy register is set with the .DAT slot number and the .CLOSE register is set non-~ (-1).
At completion of the .CLOSE or .OPER function, the device handler must clear only the appropriate busy register. When the function is reexecuted with the busy register cleared but the .CLOSE register set, the contents minus 1 of the
.CLOSE register are returned in the AC to the calling program following the .CLOSE or .OPER command and the handler's .CLOSE flag is cleared by the IThe Teletype handler is an exception.
2
The CAL handler validates Background arguments in Monitor calls. The test based on the setting of the hardware memory protect bound uses the contents of .SCOM+32, which is not set to zero by the $MPOFF command.
3Mus t be assembled with contents
= S.
7-10
Monitor. The handler is not entered a second time. The contents minus 1 of the /function and subfunction codes, the /CAL handler places a JMP to the