CA1092714A - Extended interruption handling - Google Patents
Extended interruption handlingInfo
- Publication number
- CA1092714A CA1092714A CA291,137A CA291137A CA1092714A CA 1092714 A CA1092714 A CA 1092714A CA 291137 A CA291137 A CA 291137A CA 1092714 A CA1092714 A CA 1092714A
- Authority
- CA
- Canada
- Prior art keywords
- program
- interruption
- request
- class
- handling
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Executing Machine-Instructions (AREA)
- Debugging And Monitoring (AREA)
- Multi Processors (AREA)
Abstract
EXTENDED INTERRUPTION HANDLING
ABSTRACT OF THE DISCLOSURE
.
A program instruction designated TEST PENDING INTERRUP-TION (TPI) provides for recursive handling of non-specific interruptions in a specific class of interruptions without displacement of program status or environmental information.
The instruction is located at a "terminal" position in a supervisory program for handling interruptions in the specific class. Its execution operates to set a condition code, clear an active request for interruption in the specific class (if at least one request in said class is pending) and store information accessible to the program identifying the source of the cleared request. Although the system controls for accepting non-specific interruption may be disabled during execution of any instruction such disability does not affect execution of this instruction. The condition code set by the instruction enables the associated supervisory program either to return control to an interrupted program (if no request is pending in the class) or to branch to a "relatively short" subroutine for attending directly to the event associated with the request cleared by the instruction. Since the instruc-tion is executed only at a predetermined stage of the super-visory program, and only when the system controls are in a "known" state, many operations otherwise needed for handling unscheduled interruptions are not needed when TPI is used.
Consequently the program and subroutine associated with TPI
"recursion" can be much shorter (use far fewer instructions) than existing program operations for recursevely handling interruptions.
ABSTRACT OF THE DISCLOSURE
.
A program instruction designated TEST PENDING INTERRUP-TION (TPI) provides for recursive handling of non-specific interruptions in a specific class of interruptions without displacement of program status or environmental information.
The instruction is located at a "terminal" position in a supervisory program for handling interruptions in the specific class. Its execution operates to set a condition code, clear an active request for interruption in the specific class (if at least one request in said class is pending) and store information accessible to the program identifying the source of the cleared request. Although the system controls for accepting non-specific interruption may be disabled during execution of any instruction such disability does not affect execution of this instruction. The condition code set by the instruction enables the associated supervisory program either to return control to an interrupted program (if no request is pending in the class) or to branch to a "relatively short" subroutine for attending directly to the event associated with the request cleared by the instruction. Since the instruc-tion is executed only at a predetermined stage of the super-visory program, and only when the system controls are in a "known" state, many operations otherwise needed for handling unscheduled interruptions are not needed when TPI is used.
Consequently the program and subroutine associated with TPI
"recursion" can be much shorter (use far fewer instructions) than existing program operations for recursevely handling interruptions.
Description
~0!9Z714 BI~CKGROUND OF TIIE INVENTION
_ _ .
_ _ .
2 In multi-program data processing systems, such as the IBM *
3 Systems/360 or 370, it is not unusual to have control pass in
4 an oscillatory ("ping-pong") mode from an interrupting program to an interrupted program and immediately back to the same 6 interrupting program (due to existence of pending requests for 7 interruption in the same class as the interruption attended to 8 by the interrupting program). This gives rise to "wasted 9 motion" in system operation; especially in respect to operations associated with the exchange of status (and environmental) 11 information.
12 Systems such as IBM Systems/360 and 370 have in~tructions 13 for examining and conditionally clearing a specific inter-14 ruption request (e.g. instructions such as TEST I/O and CLEAR
I/O). However each such instruction i8 used only relative to 16 one specific interruption request source associated with one 17 specific class (I/O interruptions). In a system capable of 18 serving many (e.g. hundreds of) relatively asynchronous I/O
19 devices, and thereby sub;ect to having many I/O interruption requests pending concurrently, it would be extremely inefficient 21 and virtually unfeasible to use such "source-specific" instru-22 ctions to attend to all (or a moderately large subset of all) 23 pending I/O interruption requests and obviously impossible to 24 use such instructions to attend to interruption requests not related to I/O functions. However we have found that there 26 is at present a need which appears not to have been appreciated 27 or recognized by others, although nonetheless important for 28 effective operation, for having a capability to efficiently 29 link the handling of non-specific interruptions in a given *Registered Trade Mark of International Business Machines .
Corporation B ~.
109~714 1 class (or subset of a class) on a program-controllable basis 2 without having to displace environmental and/or program state 3 information. This need i8 sati6fied by the pre~ent invention.
4 SUt~lARY OF THE INVENTION
In accordance with the foregoing discus~ion the invention 6 provides a facility for smoothly linking the recursive handling 7 of interruptions in one class to the handling of an original 8 interruption in said class; which facility is: a) not inter-9 ruptible in its operation for the given class; b) operable only when the system is under control of a supervisory program;
11 and c) operable effectively without any displacement or manipu-12 lation of program status information and/or other environmental 13 information.
14 More specifically the invention provides a particular program instruction (TPI) which operates the system to: a) 16 examine a set of multiple non-specific (i.e. not specified in 17 this instruction) source~ of requests for interruption in one 18 specific class of interruptions; b) clear (terminate) one 19 pending request, if at least one is pending; c) set a condition code indicating such clearance (or non-clearance); and d) store 21 interruption code information accessible to the program 22 currently in control of the system identifying the source of a 23 cleared request (when one is cleared).
24 The invention contemplates execution of said instruction, at a point (phase) of program execution in a supervisory 26 interruption handling program associated with a said specific 27 class, ~uch that the controls of the system are effectively 28 disabled from accepting unscheduled interruptionQ in said 29 class prior to and immediately after execution of the P09-76-017 -3_ 109~714 1 instruction. Execution of sa'd instruction has the effect of 2 momentarily over-riding such disablement, and of permitting 3 "instru^tion-controlled zcceptance" of d ~on-specific inter-4 ru~tion in said class; but characterized by the absence of any s movement of status and/or environmental information associated 6 with ordinary enablement and ordinary acceptance of interruption.
7 The invention further contemplates utilization of said 8 TPI instrl.ction at a stage of program execution at which all g operations relative to servicing of an accepted interruption in said specific class have been completed and at which the 11 program i9 "prepared" to return control of said system to a 12 previously interrupted program.
13 The invention contemplates further that as a consequence 14 of instruction-controlled "acceptance" of interruption in said class, as characterized above~ the program currently in 16 control of said system when the TPI instruction is executed 17 (i.e. the program containing said instruction) is capable of 18 attending directly to the "accepted" interruption request by 19 a 8imple branch subroutine conditioned on TPI execution;
such subroutine being significantly shorter than the recursive 21 program operations which would be required otherwise to attend 22 to acceptance of an unscheduled interruption in said class.
23 Furthermore, as a corollary, such controlled "accep-24 tance" provides a basis for eliminating instructions from existing programs for recursively handling interruptions in 26 one class, and thereby for improving the utilization of system 27 resources.
28 As another corollary such controlled acceptance and 29 shortened service operation are expected to provide performance ~09Z714 1 improvements which potentiallv could-reduce the statistical 2 frequency of over-runs in ti~ne-dependent proces~es and thereby 3 pot~ntially could reduce the amount of system processing time 4 "wasted" on di~gno~tic, corrective and re-initiating pro-cedures.
6 The foregoing and other features, aspects and objectives 7 of the present invention may be more fully understood and 8 appreciated by considering the following detailed description g of the drawings and claims.
In the drawings:
11 FIG. 1 illustrates the sequence of instruction execution 12 and interruption acceptance operations in prior art environ-13 mental systems in which the subject invention may be advanta-14 geously applied and which are conveniently adaptive for such application;
16 FIG~ 2 illustrates adaptation of such environmental 17 systems in accordance with the subject invention;
18 FIG. 3 illustrates a typical application of the subject 19 invention in an environmental system supervisory program for interruption handling; and 21 FIG. 4 illustrates for comparative purposes "prior art"
22 programming of such environmental systems for recursive handling 23 of interruptions in a common class.
FIG. 1 illustrates the sequence of operations associated 26 with execution of program instructions and acceptance of 27 unscheduled interruption in "prior art" multiprogrammed 28 computing systems which represent environmental systems 28 adaptable to utilize the subject invention advantageously;
in particular, IBM System/360 and 370 systems.
lO9Z71~
1 Architectural principles of operation and organization relevant to the present invention are given in "IBM System/370 Principles of Operation", forms A22-6821 (System/360) and GA22-7000 (Sy~tem/370).
Organizations of microprogram sequence contrQls in various models of such systems are described in U. S. Patents 3,400,371 (Gran,ted September 3, 1968 to G. M. Amdahl et al) and 3,585,599 (Granted June 15, 1971 to D. C. Hitt et al); and in "Microprogram Control For System/360" by S. Tucker, IBM Svstems Journal, Vol.
6, No. 4., pp 222-241.
Operating System (Supervisory) programs for performing interruption handling services relevant to the present descrip-tion are given in: Forms GC28-5634 (Introduction to OS) and GC28-6535 (OS Concepts And Facilities) and SY26-3823 (OS/VS2 I/O
Supervisor Logic) and SY28-0716 (OS/VS2 System Logic Library).
FIG. 1 illustrates the sequence of execution of program instruction~ and unscheduled interruptions in the environmental systems. Program instructions are executed by actions of system sequence controls (e.g. microprogram controls) which serve to perform the actions of (1.1) fetching an instruction at a storage address usually designated by an instruction address count, (1.2) decoding the operation code portion of the instruction and (1.3) executing the operations designated or called for by the instruction. The execution action associated with certain instructions defined in the above architectural references includes the setting of a condition code as suggested at 1.3.1.
.
1 Between '~he terminal Gperation (END OP) of the execution 2 of one instruction (position 1.3.2 in FIG. 1) and the fetching 3 of thl~ next instruction (position 1~1 in FIG. 1) the sequence 4 controls of the system may be enabled to operate independent of the program currently in control to accept interruption 6 (position 1.4, FIG. 1). The controls determine whether the 7 system is enabled at this particular time (in its existing 8 program state) for accepting interruptions (position 1.4.1).
9 If the system is not enabled the next instruction is fetched (action 1.1). If the system is enabled the controls test for 11 the existence cf unmasked interruption requests (position 12 1.4.2, FIG. 1). If no unmasked interruption requests are pend-13 ing the controls again pass directly to the fetching of the next 14 instruction at 1.1. On the other hand, if at least one un-masked request for interruption is pending the controls perform 16 the operations 1.4.3 associated with acceptance of interruption.
17 If more than one request is pending a priority selection 18 is made of one request (operation 1.4.3.1, FIG. 1) and that 19 request i9 cleared (1.4.3.2). If only one request is pending that request is cleared. Clearance of the request means that 21 the indication manifesting the request is terminated. An 22 interruption code associated with the selected request is 23 stored (operation 1.4.3.3) and environmental information is 24 exchanged (operation 1.4.3.4) to transfer control from the program associated with the last-executed instruction to a 26 program for handling the interruption designated by the 27 selected request. These operations are fully described in the 28 foregoing architectural references and in above-referenced 29 U`. S. Patent 3,400,371.
~092714 1 In this exchange a "new" PSW (program status word) 2 assoclated with the interruption handli~ program i3 retrieved 3 from storage and an "old" PSW associated with the interrupted 4 program (i.e. the program containing the last executed instru-ction) is stored for future reference. The sequence controls 6 then pass to the action 1.1 for fetching the first instruction 7 of a supervisory program for interruption handling (IH).
8 The subject instruction (TPI) is intended to be used to 9 initiate recursive action within interruption handling programs of such environmental systems. As shown in FIG. 2 the subject 11 instruction (indicated at 2.1) contains an eight-bit operation 12 code (OP Code) shown at 2.1.1 and an eight-bit field 2.1.2 which 13 is either unused or may be used as described below to distinguish 14 the class of interruption requests which may be "tested" by the instruction. The system sequence controls 2.2 for decoding 16 instructions are provided with an extra decoding point 2.2.1 17 uniquely associated with the subject instruction. As indicated 18 in FIG. 2 with the exception of line 2.2.1 (and the code 19 recognition logic associated with said line) the controls 2.2 are essentially identical with the controls 1.2 of FIG. 1 and 21 in response to OP Codes other than that at 2.1.1 provide outputs 22 to the "normal" execution controls 1.3 of FIG. 1.
23 With the marking of TPI line 2.2.1 action is taken to 24 determine the class of interruptions associated with the interruption handling program containing the TPI instruction 26 which has just been decoded. The logic for making this deter-27 mination is indicated schematically at 203 and 2.4 in FIG. 2.
28 Class information distinguishing the class of interruption 29 currently being handled (e.g. I/O interruption, external 10927~4 1 interruption, program interruption, etc.) may be used to 2 enable corre~ponding AN~ circuits (2.3.1 for I/O interruption, 3 2.3.2 for external interruption, 2.3.3 for program interruption, 4 etc.). one of which is thereby prepared to produce output S excitation when line 2.2.1 is excited. The class information 6 may be prepared in a register by the program. As an alternative 7 the operation code 2.1.1 of the instruction may be used to 8 distinguish class by having a different operation code for each 9 class. Another alternative would be to use space 2.1.2 of the instruction to distinguish the class. Furthermore it should 11 be obvious that if the TPI instruction were to be employed 12 only relative to one class (e.g. I/O interruptions) then the 13 foregoing class distinction would not be required and the 14 logic indicated at 2.3 and 2.4 would not be required.
Taking the class of I/O interruptions as representative 16 the action of execution of the associated TPI instruction 17 proceeds as follows (after action 2.3.1). At 2.5 the execution 18 sequence controls determine whether an interruption in the 19 respective class (i.e. I/O interruption class) is pending currently. Obviously this action is a subset of the action 21 shown at 1.4.2 in FIG. 1 and may be adapted in the environmental 22 system using a subset of the associated logic. If no active 23 request is pending in the associated class the condition code 24 is set to 0 as shown at 2.6 and the execution sequence termi-nates at 2.7 with the usual terminal operation of instruction 26 execution (END OP); i.e. the point 1.3.2 in FIG. 1 at which 27 the controls pass to the action 1.4 for general acceptance 28 of unscheduled interruption in non-specific classes.
1092'71~
1 On the ~ther hand if at te~t 2.5 an active interruption 2 request is pending in the associated class the controls for 3 exec~lting the TP.I instruction perform operations 2.8 consisting 4 of the setting of the condition code to state 1 (2.8.1), selec-tion of one active request in the specific class (I/O Inter-6 ruption) according to a predetermined priority schedule (2.8.2), 7 the clearance of the selected request (2.8.3) and the storage 8 of the interruption code associat~d with the selected request 9 (2.8.4). The actions of request selection, request clearance and interruption code storage constitute a subset of the actions 11 shown at 1.4.3 in FIG. 1 (excluding the PSW exchange) and may 12 be implemented by similar logic or by using the existing logic 13 associated with actions 1.4.3 through re-entrant microprogramming.
14 Upon completing the actions 2.8 the controls pass via terminal operation 2.7/1.3.2 (END OP) to the conventional 16 sequence 1.4 for conditional acceptance of interruptions in 17 nonspecific classes.
18 The application of the ~ubject instruction in a super-19 visory program for ~andling I/O interruption is indicated in FIG. 3. A comparative presentation of prior art recursive 21 handling is presented in FIG. 4. An arbitrary program X
22 (shown at 3.1 in FIG. 3 and 4.1 in FIG. 4) is presumed to be 23 interrupted by acceptance of an I/O interruption request (at 24 3.2 in FIG. 3; 4.2 in FIG. 4) in accordance with actions 1.4 in FIG. 1. Individual program instruction actions are 26 indicated schematically by horizontal lines; as shown for 27 instance at 3.1.1.
28 In the initial stage of programmed interruption handling 29 after acceptance ~first level interruption handling or FLIH), P09-76-017 -10-.
10~714 1 indicated at 3.3 in FIG. 3 and 4.3 in FIG. 4, the supervisory 2 program for interruption handling determines 'he cause of 3 interruption and stores any additional environmental information 4 which may b~ required relative to the further handling of said interruption. In an advanced stage of interruption handling 6 (second level interruption handling or SLIH), shown at 3.4 7 in FIG. 3 and 4.4 in FIG. 4, the program performs actions 8 required to service the interruption. In the case of I/O
9 interruption such actions may i~volve for instance storage displacement of channel status word (CSW) information relative 11 to a specific I/0 channel.
12 Instruction 3.4.2 in the second level sequence 3.4 is 13 executed initially later than the first instruction 3.4.1 in 14 the same sequence and represents an initial point of recursive entry uniquely associated with the execution of a TPI instruction 16 as described below. As indicated at 3.5 execution of TPI sets 17 a condition code 0 or 1 as described previously. A branch 18 instruction shown at 3.6 tests this code.
19 If condition code 0 is set the program is sequenced by the branch instruction to a Load PSW (LPSW) instruction shown 21 at 3.7. This loads the "old" PSW into the system registers 22 and effectively returns control of the system to the interrupted 23 program (X); at the instruction 3.8 which would have been 24 executed next if interruption had not been accepted at 3.2.
If condition code 1 is set by the TPI instruction branch 26 instruction 3.6 branches the program as suggested at 3.6.1 27 into its recursive entry point 3.4.2. From this point the 28 program 3.4 proceeds to perform only operations associated with 29 the handling of the interruption request cleared by the TPI
lOgZ7~4 1 exeeution actior, as set forth previously. Since the TPI
2 instruction and its associated branch instruction are located 3 at a "final`' position in the interruption handling program 4 (just prior to the return of control to the interrupted program X), and ~ince the TPI instruction invariably selects 6 an interruption in the same class as the interruption just 7 handled, it may be appreciated that there is no need to 8 displace status or environmental information upon or in g association with TPI execution. Furthermore since the TPI
instruction is provided explicitly at such final position in 11 the interruption handling program the program "knows" implicit-12 ly that all actions relative to the handling of the previous 13 interruption have been completed and that the interruption 14 request which must be serviced is identified by the currently stored interruption code (i.e. the code overwritten by TPI
16 execution). Therefore a status exchange is not required and 17 a minimal program routine may be u9ed to complete the handling 18 Of the interruption "taken" by the action of TPI execution.
19 By way of contrast the first level interruption handling sequence at 4.3 in FIG. 4 includes a preparational subsequence 21 shown at 4.3.1 which is not needed when TPI i8 used. The 22 preparational sequence moves the program status information 23 associated with program X temporarily to a backup storage 24 position in anticipation of a further program status exchange described below and further conditions the program to be able 26 to "skip" over unnecessary program steps during recursive .
27 interruption handling as described below.
28 In the second level interruption handling sequence 4.4, 29 at a point 4.4.1 which is reached after all actions relative ~09Z7~4 1 to the interruption accepted at 4.2 have been performed, the 2 program contains an instruction for setting an enabling bit 3 in the program status word which is currently in control of 4 the system. This enables the system for recur~ive acceptance of interruption at 4.6 in the class (I/O) associated with the 6 interruption accepted at 4.2. If no requests are pending in 7 said class the program advances to instruction 4.5.1 in 8 segment 4.5 of the second level program for interruption 9 handling. Instruction 4.5.1 resets the enabling bit in the PSW to a disabling condition and the program proceeds at 4.7 11 to restore the environment which existed in the system prior 12 to the preparational sequence 4.3.1. When this is accomplished 13 the Load PSW instruction 4.8 is executed to return control to 14 interrupted program X at 4.9.
If an I/O interruption request is accepted at 4.6 the PSW
16 exchange 1.4.3.4 and other actions 1.4 of FIG. 1 are carried 17 out at 4.6. The "new" PSW contains the address of instruction 18 4.3.2 entered via recursive entry path 4.6.1 at an initial 19 stage of first level interruption handling program 4.3. By virtue of the preparation performed at 4.3.1 the interruption 21 handling program proceeds to perform the requisite operations 22 but skips many of the steps which are performed ordinarily 23 during a first pass through the program from acceptance stage 24 4.2. Eventually the program returns to enablement stage 4.4.1 and, if no further interruptions are accepted at 4.6, to the 26 disablement stage 4.5.1. The environmental restoration opera-27 tions 4.7.1 place the program in the state prior to preparation 28 operations 4.3.1 after which the interrupted program X is 29 returned to control by Load PSW 4.8. Quite clearly considering 10~ 4 1 FIGS. 3 and 4 comparatively it becomes evident that with the 2 TPI instruction the program status exchange at 4.6 ~s avoided 3 and the preparational actions 4.3.1 and restorative actions 4 4.7.1 may be eliminated thereby shortening the interruption handling program.
6 While the invention has been particularly shown and 7 described with reference to preferred embodiments thereof, it 8 will be understood by those skilled in the art that the above 9 and other changes in form and details may be made therein without departing from the spirit and scope of the invention.
RL:ehc
12 Systems such as IBM Systems/360 and 370 have in~tructions 13 for examining and conditionally clearing a specific inter-14 ruption request (e.g. instructions such as TEST I/O and CLEAR
I/O). However each such instruction i8 used only relative to 16 one specific interruption request source associated with one 17 specific class (I/O interruptions). In a system capable of 18 serving many (e.g. hundreds of) relatively asynchronous I/O
19 devices, and thereby sub;ect to having many I/O interruption requests pending concurrently, it would be extremely inefficient 21 and virtually unfeasible to use such "source-specific" instru-22 ctions to attend to all (or a moderately large subset of all) 23 pending I/O interruption requests and obviously impossible to 24 use such instructions to attend to interruption requests not related to I/O functions. However we have found that there 26 is at present a need which appears not to have been appreciated 27 or recognized by others, although nonetheless important for 28 effective operation, for having a capability to efficiently 29 link the handling of non-specific interruptions in a given *Registered Trade Mark of International Business Machines .
Corporation B ~.
109~714 1 class (or subset of a class) on a program-controllable basis 2 without having to displace environmental and/or program state 3 information. This need i8 sati6fied by the pre~ent invention.
4 SUt~lARY OF THE INVENTION
In accordance with the foregoing discus~ion the invention 6 provides a facility for smoothly linking the recursive handling 7 of interruptions in one class to the handling of an original 8 interruption in said class; which facility is: a) not inter-9 ruptible in its operation for the given class; b) operable only when the system is under control of a supervisory program;
11 and c) operable effectively without any displacement or manipu-12 lation of program status information and/or other environmental 13 information.
14 More specifically the invention provides a particular program instruction (TPI) which operates the system to: a) 16 examine a set of multiple non-specific (i.e. not specified in 17 this instruction) source~ of requests for interruption in one 18 specific class of interruptions; b) clear (terminate) one 19 pending request, if at least one is pending; c) set a condition code indicating such clearance (or non-clearance); and d) store 21 interruption code information accessible to the program 22 currently in control of the system identifying the source of a 23 cleared request (when one is cleared).
24 The invention contemplates execution of said instruction, at a point (phase) of program execution in a supervisory 26 interruption handling program associated with a said specific 27 class, ~uch that the controls of the system are effectively 28 disabled from accepting unscheduled interruptionQ in said 29 class prior to and immediately after execution of the P09-76-017 -3_ 109~714 1 instruction. Execution of sa'd instruction has the effect of 2 momentarily over-riding such disablement, and of permitting 3 "instru^tion-controlled zcceptance" of d ~on-specific inter-4 ru~tion in said class; but characterized by the absence of any s movement of status and/or environmental information associated 6 with ordinary enablement and ordinary acceptance of interruption.
7 The invention further contemplates utilization of said 8 TPI instrl.ction at a stage of program execution at which all g operations relative to servicing of an accepted interruption in said specific class have been completed and at which the 11 program i9 "prepared" to return control of said system to a 12 previously interrupted program.
13 The invention contemplates further that as a consequence 14 of instruction-controlled "acceptance" of interruption in said class, as characterized above~ the program currently in 16 control of said system when the TPI instruction is executed 17 (i.e. the program containing said instruction) is capable of 18 attending directly to the "accepted" interruption request by 19 a 8imple branch subroutine conditioned on TPI execution;
such subroutine being significantly shorter than the recursive 21 program operations which would be required otherwise to attend 22 to acceptance of an unscheduled interruption in said class.
23 Furthermore, as a corollary, such controlled "accep-24 tance" provides a basis for eliminating instructions from existing programs for recursively handling interruptions in 26 one class, and thereby for improving the utilization of system 27 resources.
28 As another corollary such controlled acceptance and 29 shortened service operation are expected to provide performance ~09Z714 1 improvements which potentiallv could-reduce the statistical 2 frequency of over-runs in ti~ne-dependent proces~es and thereby 3 pot~ntially could reduce the amount of system processing time 4 "wasted" on di~gno~tic, corrective and re-initiating pro-cedures.
6 The foregoing and other features, aspects and objectives 7 of the present invention may be more fully understood and 8 appreciated by considering the following detailed description g of the drawings and claims.
In the drawings:
11 FIG. 1 illustrates the sequence of instruction execution 12 and interruption acceptance operations in prior art environ-13 mental systems in which the subject invention may be advanta-14 geously applied and which are conveniently adaptive for such application;
16 FIG~ 2 illustrates adaptation of such environmental 17 systems in accordance with the subject invention;
18 FIG. 3 illustrates a typical application of the subject 19 invention in an environmental system supervisory program for interruption handling; and 21 FIG. 4 illustrates for comparative purposes "prior art"
22 programming of such environmental systems for recursive handling 23 of interruptions in a common class.
FIG. 1 illustrates the sequence of operations associated 26 with execution of program instructions and acceptance of 27 unscheduled interruption in "prior art" multiprogrammed 28 computing systems which represent environmental systems 28 adaptable to utilize the subject invention advantageously;
in particular, IBM System/360 and 370 systems.
lO9Z71~
1 Architectural principles of operation and organization relevant to the present invention are given in "IBM System/370 Principles of Operation", forms A22-6821 (System/360) and GA22-7000 (Sy~tem/370).
Organizations of microprogram sequence contrQls in various models of such systems are described in U. S. Patents 3,400,371 (Gran,ted September 3, 1968 to G. M. Amdahl et al) and 3,585,599 (Granted June 15, 1971 to D. C. Hitt et al); and in "Microprogram Control For System/360" by S. Tucker, IBM Svstems Journal, Vol.
6, No. 4., pp 222-241.
Operating System (Supervisory) programs for performing interruption handling services relevant to the present descrip-tion are given in: Forms GC28-5634 (Introduction to OS) and GC28-6535 (OS Concepts And Facilities) and SY26-3823 (OS/VS2 I/O
Supervisor Logic) and SY28-0716 (OS/VS2 System Logic Library).
FIG. 1 illustrates the sequence of execution of program instruction~ and unscheduled interruptions in the environmental systems. Program instructions are executed by actions of system sequence controls (e.g. microprogram controls) which serve to perform the actions of (1.1) fetching an instruction at a storage address usually designated by an instruction address count, (1.2) decoding the operation code portion of the instruction and (1.3) executing the operations designated or called for by the instruction. The execution action associated with certain instructions defined in the above architectural references includes the setting of a condition code as suggested at 1.3.1.
.
1 Between '~he terminal Gperation (END OP) of the execution 2 of one instruction (position 1.3.2 in FIG. 1) and the fetching 3 of thl~ next instruction (position 1~1 in FIG. 1) the sequence 4 controls of the system may be enabled to operate independent of the program currently in control to accept interruption 6 (position 1.4, FIG. 1). The controls determine whether the 7 system is enabled at this particular time (in its existing 8 program state) for accepting interruptions (position 1.4.1).
9 If the system is not enabled the next instruction is fetched (action 1.1). If the system is enabled the controls test for 11 the existence cf unmasked interruption requests (position 12 1.4.2, FIG. 1). If no unmasked interruption requests are pend-13 ing the controls again pass directly to the fetching of the next 14 instruction at 1.1. On the other hand, if at least one un-masked request for interruption is pending the controls perform 16 the operations 1.4.3 associated with acceptance of interruption.
17 If more than one request is pending a priority selection 18 is made of one request (operation 1.4.3.1, FIG. 1) and that 19 request i9 cleared (1.4.3.2). If only one request is pending that request is cleared. Clearance of the request means that 21 the indication manifesting the request is terminated. An 22 interruption code associated with the selected request is 23 stored (operation 1.4.3.3) and environmental information is 24 exchanged (operation 1.4.3.4) to transfer control from the program associated with the last-executed instruction to a 26 program for handling the interruption designated by the 27 selected request. These operations are fully described in the 28 foregoing architectural references and in above-referenced 29 U`. S. Patent 3,400,371.
~092714 1 In this exchange a "new" PSW (program status word) 2 assoclated with the interruption handli~ program i3 retrieved 3 from storage and an "old" PSW associated with the interrupted 4 program (i.e. the program containing the last executed instru-ction) is stored for future reference. The sequence controls 6 then pass to the action 1.1 for fetching the first instruction 7 of a supervisory program for interruption handling (IH).
8 The subject instruction (TPI) is intended to be used to 9 initiate recursive action within interruption handling programs of such environmental systems. As shown in FIG. 2 the subject 11 instruction (indicated at 2.1) contains an eight-bit operation 12 code (OP Code) shown at 2.1.1 and an eight-bit field 2.1.2 which 13 is either unused or may be used as described below to distinguish 14 the class of interruption requests which may be "tested" by the instruction. The system sequence controls 2.2 for decoding 16 instructions are provided with an extra decoding point 2.2.1 17 uniquely associated with the subject instruction. As indicated 18 in FIG. 2 with the exception of line 2.2.1 (and the code 19 recognition logic associated with said line) the controls 2.2 are essentially identical with the controls 1.2 of FIG. 1 and 21 in response to OP Codes other than that at 2.1.1 provide outputs 22 to the "normal" execution controls 1.3 of FIG. 1.
23 With the marking of TPI line 2.2.1 action is taken to 24 determine the class of interruptions associated with the interruption handling program containing the TPI instruction 26 which has just been decoded. The logic for making this deter-27 mination is indicated schematically at 203 and 2.4 in FIG. 2.
28 Class information distinguishing the class of interruption 29 currently being handled (e.g. I/O interruption, external 10927~4 1 interruption, program interruption, etc.) may be used to 2 enable corre~ponding AN~ circuits (2.3.1 for I/O interruption, 3 2.3.2 for external interruption, 2.3.3 for program interruption, 4 etc.). one of which is thereby prepared to produce output S excitation when line 2.2.1 is excited. The class information 6 may be prepared in a register by the program. As an alternative 7 the operation code 2.1.1 of the instruction may be used to 8 distinguish class by having a different operation code for each 9 class. Another alternative would be to use space 2.1.2 of the instruction to distinguish the class. Furthermore it should 11 be obvious that if the TPI instruction were to be employed 12 only relative to one class (e.g. I/O interruptions) then the 13 foregoing class distinction would not be required and the 14 logic indicated at 2.3 and 2.4 would not be required.
Taking the class of I/O interruptions as representative 16 the action of execution of the associated TPI instruction 17 proceeds as follows (after action 2.3.1). At 2.5 the execution 18 sequence controls determine whether an interruption in the 19 respective class (i.e. I/O interruption class) is pending currently. Obviously this action is a subset of the action 21 shown at 1.4.2 in FIG. 1 and may be adapted in the environmental 22 system using a subset of the associated logic. If no active 23 request is pending in the associated class the condition code 24 is set to 0 as shown at 2.6 and the execution sequence termi-nates at 2.7 with the usual terminal operation of instruction 26 execution (END OP); i.e. the point 1.3.2 in FIG. 1 at which 27 the controls pass to the action 1.4 for general acceptance 28 of unscheduled interruption in non-specific classes.
1092'71~
1 On the ~ther hand if at te~t 2.5 an active interruption 2 request is pending in the associated class the controls for 3 exec~lting the TP.I instruction perform operations 2.8 consisting 4 of the setting of the condition code to state 1 (2.8.1), selec-tion of one active request in the specific class (I/O Inter-6 ruption) according to a predetermined priority schedule (2.8.2), 7 the clearance of the selected request (2.8.3) and the storage 8 of the interruption code associat~d with the selected request 9 (2.8.4). The actions of request selection, request clearance and interruption code storage constitute a subset of the actions 11 shown at 1.4.3 in FIG. 1 (excluding the PSW exchange) and may 12 be implemented by similar logic or by using the existing logic 13 associated with actions 1.4.3 through re-entrant microprogramming.
14 Upon completing the actions 2.8 the controls pass via terminal operation 2.7/1.3.2 (END OP) to the conventional 16 sequence 1.4 for conditional acceptance of interruptions in 17 nonspecific classes.
18 The application of the ~ubject instruction in a super-19 visory program for ~andling I/O interruption is indicated in FIG. 3. A comparative presentation of prior art recursive 21 handling is presented in FIG. 4. An arbitrary program X
22 (shown at 3.1 in FIG. 3 and 4.1 in FIG. 4) is presumed to be 23 interrupted by acceptance of an I/O interruption request (at 24 3.2 in FIG. 3; 4.2 in FIG. 4) in accordance with actions 1.4 in FIG. 1. Individual program instruction actions are 26 indicated schematically by horizontal lines; as shown for 27 instance at 3.1.1.
28 In the initial stage of programmed interruption handling 29 after acceptance ~first level interruption handling or FLIH), P09-76-017 -10-.
10~714 1 indicated at 3.3 in FIG. 3 and 4.3 in FIG. 4, the supervisory 2 program for interruption handling determines 'he cause of 3 interruption and stores any additional environmental information 4 which may b~ required relative to the further handling of said interruption. In an advanced stage of interruption handling 6 (second level interruption handling or SLIH), shown at 3.4 7 in FIG. 3 and 4.4 in FIG. 4, the program performs actions 8 required to service the interruption. In the case of I/O
9 interruption such actions may i~volve for instance storage displacement of channel status word (CSW) information relative 11 to a specific I/0 channel.
12 Instruction 3.4.2 in the second level sequence 3.4 is 13 executed initially later than the first instruction 3.4.1 in 14 the same sequence and represents an initial point of recursive entry uniquely associated with the execution of a TPI instruction 16 as described below. As indicated at 3.5 execution of TPI sets 17 a condition code 0 or 1 as described previously. A branch 18 instruction shown at 3.6 tests this code.
19 If condition code 0 is set the program is sequenced by the branch instruction to a Load PSW (LPSW) instruction shown 21 at 3.7. This loads the "old" PSW into the system registers 22 and effectively returns control of the system to the interrupted 23 program (X); at the instruction 3.8 which would have been 24 executed next if interruption had not been accepted at 3.2.
If condition code 1 is set by the TPI instruction branch 26 instruction 3.6 branches the program as suggested at 3.6.1 27 into its recursive entry point 3.4.2. From this point the 28 program 3.4 proceeds to perform only operations associated with 29 the handling of the interruption request cleared by the TPI
lOgZ7~4 1 exeeution actior, as set forth previously. Since the TPI
2 instruction and its associated branch instruction are located 3 at a "final`' position in the interruption handling program 4 (just prior to the return of control to the interrupted program X), and ~ince the TPI instruction invariably selects 6 an interruption in the same class as the interruption just 7 handled, it may be appreciated that there is no need to 8 displace status or environmental information upon or in g association with TPI execution. Furthermore since the TPI
instruction is provided explicitly at such final position in 11 the interruption handling program the program "knows" implicit-12 ly that all actions relative to the handling of the previous 13 interruption have been completed and that the interruption 14 request which must be serviced is identified by the currently stored interruption code (i.e. the code overwritten by TPI
16 execution). Therefore a status exchange is not required and 17 a minimal program routine may be u9ed to complete the handling 18 Of the interruption "taken" by the action of TPI execution.
19 By way of contrast the first level interruption handling sequence at 4.3 in FIG. 4 includes a preparational subsequence 21 shown at 4.3.1 which is not needed when TPI i8 used. The 22 preparational sequence moves the program status information 23 associated with program X temporarily to a backup storage 24 position in anticipation of a further program status exchange described below and further conditions the program to be able 26 to "skip" over unnecessary program steps during recursive .
27 interruption handling as described below.
28 In the second level interruption handling sequence 4.4, 29 at a point 4.4.1 which is reached after all actions relative ~09Z7~4 1 to the interruption accepted at 4.2 have been performed, the 2 program contains an instruction for setting an enabling bit 3 in the program status word which is currently in control of 4 the system. This enables the system for recur~ive acceptance of interruption at 4.6 in the class (I/O) associated with the 6 interruption accepted at 4.2. If no requests are pending in 7 said class the program advances to instruction 4.5.1 in 8 segment 4.5 of the second level program for interruption 9 handling. Instruction 4.5.1 resets the enabling bit in the PSW to a disabling condition and the program proceeds at 4.7 11 to restore the environment which existed in the system prior 12 to the preparational sequence 4.3.1. When this is accomplished 13 the Load PSW instruction 4.8 is executed to return control to 14 interrupted program X at 4.9.
If an I/O interruption request is accepted at 4.6 the PSW
16 exchange 1.4.3.4 and other actions 1.4 of FIG. 1 are carried 17 out at 4.6. The "new" PSW contains the address of instruction 18 4.3.2 entered via recursive entry path 4.6.1 at an initial 19 stage of first level interruption handling program 4.3. By virtue of the preparation performed at 4.3.1 the interruption 21 handling program proceeds to perform the requisite operations 22 but skips many of the steps which are performed ordinarily 23 during a first pass through the program from acceptance stage 24 4.2. Eventually the program returns to enablement stage 4.4.1 and, if no further interruptions are accepted at 4.6, to the 26 disablement stage 4.5.1. The environmental restoration opera-27 tions 4.7.1 place the program in the state prior to preparation 28 operations 4.3.1 after which the interrupted program X is 29 returned to control by Load PSW 4.8. Quite clearly considering 10~ 4 1 FIGS. 3 and 4 comparatively it becomes evident that with the 2 TPI instruction the program status exchange at 4.6 ~s avoided 3 and the preparational actions 4.3.1 and restorative actions 4 4.7.1 may be eliminated thereby shortening the interruption handling program.
6 While the invention has been particularly shown and 7 described with reference to preferred embodiments thereof, it 8 will be understood by those skilled in the art that the above 9 and other changes in form and details may be made therein without departing from the spirit and scope of the invention.
RL:ehc
Claims (5)
1. In a multi-program data processing system a facility for linking the recursive handling of non-specific interrup-tions in one class of interruptions to the programmed handling of an original interruption in said one class without dis-placement of stored program status, comprising:
means responsive to information, in a supervisory program for handling interruptions in said one class, for causing said system to determine pendency or non-pendency of an active request for interruption, relative to a set of non-specific interruption request sources associated with said one class;
and means cooperative with said means to determine pendency or non-pendency, and responsive to a determination that at least one source in said non-specific set has a pending (unserviced) request, for causing said system to: a) select one pending request in said set; b) terminate the selected request; c) store interruption code information specifically identifying the source of the selected request; and d) con-dition said system for recursively entering said supervisory program to perform operations for handling (servicing) said selected request; operations caused by said cooperative means being characterized in that program status information stored in said system is not displaced in preparation for said recursive entry.
means responsive to information, in a supervisory program for handling interruptions in said one class, for causing said system to determine pendency or non-pendency of an active request for interruption, relative to a set of non-specific interruption request sources associated with said one class;
and means cooperative with said means to determine pendency or non-pendency, and responsive to a determination that at least one source in said non-specific set has a pending (unserviced) request, for causing said system to: a) select one pending request in said set; b) terminate the selected request; c) store interruption code information specifically identifying the source of the selected request; and d) con-dition said system for recursively entering said supervisory program to perform operations for handling (servicing) said selected request; operations caused by said cooperative means being characterized in that program status information stored in said system is not displaced in preparation for said recursive entry.
2. A facility in accordance with Claim 1 characterized in that said system is susceptible of being disabled from accepting interruptions in said one class prior to said determination of pendency or non-pendency and immediately after said determination.
CLAIMS 1 and 2
CLAIMS 1 and 2
3. A facility in accordance with Claim 1 wherein said means to determine pendency and said cooperative means are responsive to a program instruction (TPI) of predetermined form.
4. In a multi-program data processing system a method for linking recursive handling of non-specific interruptions in one class within a supervisory program for handling interruptions in said one class comprising the steps of:
distinguishing between pendency and non-pendency of a non-specific request for interruption in said one class at a predetermined stage of execution of said supervisory program;
setting a condition code for program branching indicating the results of said distinguishing step;
terminating a selected said pending request conditional upon having distinguished pendency of at least one said request;
storing interruption code information identifying the source of said conditionally terminated request; and disabling said system from accepting interruptions in an uncontrolled mode and from otherwise modifying its program state during or in association with the execution of said distinguishing, setting, terminating and storing steps.
distinguishing between pendency and non-pendency of a non-specific request for interruption in said one class at a predetermined stage of execution of said supervisory program;
setting a condition code for program branching indicating the results of said distinguishing step;
terminating a selected said pending request conditional upon having distinguished pendency of at least one said request;
storing interruption code information identifying the source of said conditionally terminated request; and disabling said system from accepting interruptions in an uncontrolled mode and from otherwise modifying its program state during or in association with the execution of said distinguishing, setting, terminating and storing steps.
5. A method for linking recursive interruption handling according to Claim 4 comprising:
executing said distinguishing, setting, terminating, storing and disabling steps in response to a single program instruction.
CLAIMS 3, 4 and 5
executing said distinguishing, setting, terminating, storing and disabling steps in response to a single program instruction.
CLAIMS 3, 4 and 5
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US75916477A | 1977-01-13 | 1977-01-13 | |
| US759,164 | 1991-09-13 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA1092714A true CA1092714A (en) | 1980-12-30 |
Family
ID=25054630
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA291,137A Expired CA1092714A (en) | 1977-01-13 | 1977-11-17 | Extended interruption handling |
Country Status (8)
| Country | Link |
|---|---|
| JP (1) | JPS5394846A (en) |
| AU (1) | AU520734B2 (en) |
| BR (1) | BR7708760A (en) |
| CA (1) | CA1092714A (en) |
| CH (1) | CH631820A5 (en) |
| ES (1) | ES464591A1 (en) |
| GB (1) | GB1584419A (en) |
| IT (1) | IT1115694B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5341482A (en) * | 1987-03-20 | 1994-08-23 | Digital Equipment Corporation | Method for synchronization of arithmetic exceptions in central processing units having pipelined execution units simultaneously executing instructions |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS59211141A (en) * | 1983-05-16 | 1984-11-29 | Omron Tateisi Electronics Co | Interruption processing system |
| US10282327B2 (en) * | 2017-01-19 | 2019-05-07 | International Business Machines Corporation | Test pending external interruption instruction |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS5137499A (en) * | 1974-09-27 | 1976-03-29 | Ishikawajima Harima Heavy Ind |
-
1977
- 1977-11-17 CA CA291,137A patent/CA1092714A/en not_active Expired
- 1977-11-30 ES ES464591A patent/ES464591A1/en not_active Expired
- 1977-12-09 GB GB5143077A patent/GB1584419A/en not_active Expired
- 1977-12-16 IT IT3079077A patent/IT1115694B/en active
- 1977-12-20 JP JP15251677A patent/JPS5394846A/en active Granted
- 1977-12-23 CH CH1597077A patent/CH631820A5/en not_active IP Right Cessation
- 1977-12-29 BR BR7708760A patent/BR7708760A/en unknown
-
1978
- 1978-01-11 AU AU32360/78A patent/AU520734B2/en not_active Expired
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5341482A (en) * | 1987-03-20 | 1994-08-23 | Digital Equipment Corporation | Method for synchronization of arithmetic exceptions in central processing units having pipelined execution units simultaneously executing instructions |
Also Published As
| Publication number | Publication date |
|---|---|
| ES464591A1 (en) | 1978-09-01 |
| GB1584419A (en) | 1981-02-11 |
| BR7708760A (en) | 1979-07-24 |
| IT1115694B (en) | 1986-02-03 |
| JPS5394846A (en) | 1978-08-19 |
| AU520734B2 (en) | 1982-02-25 |
| AU3236078A (en) | 1979-07-19 |
| JPS5611340B2 (en) | 1981-03-13 |
| CH631820A5 (en) | 1982-08-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0090302B1 (en) | Programmable control apparatus and method | |
| US4447874A (en) | Apparatus and method for communication of information between processes in an information system | |
| US5038281A (en) | Acceleration of system interrupts between operating systems in guest-host relationship | |
| US5613114A (en) | System and method for custom context switching | |
| US4074353A (en) | Trap mechanism for a data processing system | |
| US4493034A (en) | Apparatus and method for an operating system supervisor in a data processing system | |
| US3781810A (en) | Scheme for saving and restoring register contents in a data processor | |
| EP0383474B1 (en) | Processor interrupt control | |
| US5386563A (en) | Register substitution during exception processing | |
| US4342082A (en) | Program instruction mechanism for shortened recursive handling of interruptions | |
| US3905025A (en) | Data acquisition and control system including dynamic interrupt capability | |
| GB2329049A (en) | A debugger interface unit for identifying selected exceptions | |
| KR100280161B1 (en) | Out of sequence work methods and devices | |
| US4126893A (en) | Interrupt request controller for data processing system | |
| US4247894A (en) | Arrangement for program interruption | |
| TW405090B (en) | Predictive cache loading by program address discontinuity history | |
| US5551051A (en) | Isolated multiprocessing system having tracking circuit for verifyng only that the processor is executing set of entry instructions upon initiation of the system controller program | |
| US4937780A (en) | Single instruction updating of processing time field using software invisible working registers | |
| CA1092714A (en) | Extended interruption handling | |
| US3778780A (en) | Operation request block usage | |
| GB2320343A (en) | computer system with checkpoint facility | |
| US5241634A (en) | Method of handling system calls to an operating system of a computer by system service routines stored as firmware | |
| US3644936A (en) | Method for measuring performance of a general purpose digital computer | |
| AU626067B2 (en) | Apparatus and method for control of asynchronous program interrupt events in a data processing system | |
| EP0206335A2 (en) | Interruption Method for a Data Processing System |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MKEX | Expiry |