GB1584419A - Data processing apparatus - Google Patents

Abstract

In a multi-programmable data processing system, devices and measures are provided for checking, after execution of a program called up by an interrupt, whether in the meantime another interrupt request of the same type (for example input/output interrupt) has occurred so that the latter can then be served during the interrupt program which is still active. In this manner, the execution of interrupt routines of the same type can be concatenated with one another which saves data exchange processes between processor and memory which otherwise are required at the beginning and end of each interrupt. For the data processing system, a special command "interrogation for waiting interrupt request" (TPI) is provided which can be placed at the end of each interrupt routine and when this is decoded, the interrogation for waiting interrupt requests, the setting of a conditional code and the storing of an interrupt code and a branch back in the relevant program for dealing with the interrupt request found are effected via special signal lines. <IMAGE>

Description

(54) DATA PROCESSING APPARATUS (71) We, INTERNATIONAL BUSINESS MA CHINES CORPORATION, a Corporation organized and existing under the laws of the State of New York in the United States of America, of Armonk, New York 10504, United States of America, do hereby declare the invention for, which we pray that a patent may be granted to us, and the method by which it is to be performed, to be particularly described in and by the following statement The present invention relates to data processing apparatus.

The present invention provides data processing apparatus comprising a hardware/ supervisory program combination adapted to service task oriented program routines on a multiprogram interrupt basis, such service including, when an interrupt is accepted during the execution of a routine, storing the task/system profile associated with the interrupted routine, establishing a task/ system profile for the interrupting routine, invoking the interrupting routine and exiting via a branch instruction which causes the testing of pending interrupts, if any, to detect if an interrupt of the same class is pending and branches either to the invoking entry point in the supervisory program bypassing any task/ system profile storing and establishing if a pending interrupt, which is of the same class as the interrupting routine and requires no task/system profile change, is detected, thus causing execution of all such pending interrupts before return to the interrupted routine, or to a restoring routine for the interrupted task program if no interrupt of the same class is pending.

The expression "task/system profile" has been used to indicate that collection of data held in various elements of the apparatus which is sufficient for that apparatus to restore an interrupted routine.

In multi-program data processing systems, such as the IBM Systems/360 or 370 (IBM being a Registered Trade Mark), it is not unusual to have control pass in an oscillatory ("ping-pong") mode from an interrupting program to an interrupted program and immediately back to the same interrupting program (due to existence of pending requests for interruption in the same class as the interruption attended to by the interrupting program). This gives rise to "wasted motion" in system operation; especially in respect to operations associated with the exchange of status (and environmental) information.

Systems such as IBM Systems/360 and 370 have instructions for examining and conditionally clearing a specific interruption request (e.g., instructions such as TEST I/O and CLEAR I/O). However each such instruction is used only relative to one specific interruption request source associated with one specific class (I/O interruptions). In a system capable of serving many (e.g. hundreds of) relatively asynchronous I/O devices, and thereby subject to having many I/O interruption requests pending concurrently, it would be extremely inefficient and virtually unfeasible to use such "source-specific" instructions to attend to all (or a moderately large subset of all) pending I/O interruption requests and obviously impossible to use such instructions to attend to interruption requests not related to I/O functions. It is our belief that there is at present a need for having a capability to efficiently link the handling of non-specific interruptions in a given class (or subset of a class) on a program-controllable basis without having to displace environmental and/or program state information and that this need is satisfied by the present invention.

As disclosed hereinafter by way of example, one embodiment of the invention provides a facility for smoothly linking the recursive handling of interruptions in one class to the handling of an original interruption in said class; which facility is: aA not interruptible in its operation for the given class; b) operable only when the system is under control of a supervisory program; and c) operable effectively without any displacement or manipulation of program status information and/or other -environmental information.

More specifically the embodiment provides a particular program instruction (TPI) which operates the system to: a) examine a set of multiple non-specific (i.e. not specified in this instruction) sources of requests for interruption in one specific class of interruptions; b) clear (terminate) one pending request, if at least one is pending; c) set a condition code indicating such clearance (or non--dearance); and d) store interruption code information accessible to the program currently in control of the system identifying the source of a cleared request (when one is cleared).

The instruction is executed at a point (phase) of program execution in a supervisory interruption handling program associated with a said specific class, such that the controls ofthe system are effectively disabled from accepting unscheduled interruptions in said class prior to and immediately after execution of the instruction. Execution of said instruction has the effect of momentarily overriding such disablement, and of permitting-"instruc- tion-controlled acceptance" of a non-specific interruption in said class ; but characterized by the absence of any movement of status and/or environmental information associated with enablement and ordinary acceptance of interruption.

The TPI instruction is executed at a stage df program execution at which all operations relative to servicing of an accepted -interruption in said specific class have been completed and at which the program is "prepared" to return control of said - system to a previously interrupted program.

As a consequence of instruction-controlled "acceptance" of interruption in said class, the program - currently -in control of said system when the TPI instruction-is executed- (i.e. -the program containing said instruction) is capable of attending directly to the "accepted" interruption request by a simple branch subroutine conditioned on TPI execution; such subroutine being significantly shorter than the recursive -program operations which would be required otherwise to attend to acceptance of an unscheduled interruption in said class.

Furthermore, as a corollary, such controlled "acceptance" provides a basis for eliminating instructions from existing programs for recursively handling interruptions in one class, and thereby for improving the utilization of system resources.

As another corollary such controlled acceptance and shortened service operation are expected to provide performance improvements which potentially could reduce the statistical frequency of over-runs in time dependent processes and thereby potentially could reduce tbe amount of system processing time "wasted" on diagnostic, corrective and re-initiating procedures.

The aforementioned embodiment is illustrated in the accompanying drawings which also show prior arrangements with which the embodiment is contrasted.

In the drawings: Fig. 1 illustrates the sequence of instruction execution and interruption acceptance operations in prior art environmental apparatus.

Fig. 2 illustrates one form of modification to such apparatus to transform it to apparatus in accordance with the subject invention Figure 3 illustrates typical interruption handling within the modified apparatus; Fig. 4 illustrates, for comparative purposes, equivalent "prior art" recursive handling of interruptions in a common class.

Fig. 1 illustrates the sequence of operations associated with execution of program instructions and acceptance of unscheduled interruption in "prior art" multiprogrammed computing systems which represent environmental systems adaptable to utilize the subject invention advantageously; in particular, IBM System/360 and 370 systems.

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 (System/370).

Organizations of microprogram sequence controls in various models of such systems are described in U.S. Patenets 3,400,371 (Granted September 3, 1968 to G. M. Amdahl et al) and 3,585,599 (Grantd June 15, 1971 to D. -C. Hitt et al); and in "Microprogram Control For System/360" by S. Tucker,.IBM Systems Journal, Viol. 6, No. 4., pp 222-241.

Operating System (Supervisory) programs for performing interruption handling services relevant to the present description 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).

Relevant information in the foregoing references is incorporated herein by this reference.

Fig. 1 illustrates the sequence of execution of program instructions and unscheduled interruptions in the environmental systems.

Program instructions are executed by actions of system sequence controls (e.g. microprogram contrdls) 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.

Between the terminal operation (END OP) of the execution of one instruction (position 1.3.2 in Fig. 13 and the fetching of the next instruction (position 1.1 in Fig. 1) the sequence controls of the system may be enabled to operate independent of the program currently in control to accept interruption (position 1.4, Fig. 1). The controls determine whether the system is enabled at this particular time (in its existing program state) for accepting interruptions (position 1.4.1). If the system is not enabled the next instruction is fetched (action 1.1). If the system is enabled the controls test for the existence -of unmasked interruption requests (position 1.4.2, Fig. 1).

If no unmasked interruption requests are pending the controls again pass directly to the fetching of the next instruction at 1.1. On the other hand, if at least one unmasked request for interruption is pending the controls perform the -operations 1.4.3. associated with acceptance of interruption.

If more than one request is pending a priority selection is made of one request (operation 1.4.3.1, Fig. 1) and that request is cleared (1.4.3.2). If only one request is pending that request is cleared. Clearance of the request means that the indication manifesting the request is terminated. An interruption code associated with the selected request is stored (operation 1.4.3.3) and environmental information is exchanged (operation 1.4.3.4) to transfer control from the program associated with thelast-executed instruction to a program for handling the interruption designated by the selected request. These operations are fully described in the foregoing architectural references and in above-referended U.S. Patent 3,400,371.

In this exchange a "new" PSW (program status word) associated with the interruption handling program is retrieved from storage and an "old" PSW associated with the intererupted program (i.e. the program containing the last executed instruction) is stored for future -reference. The sequence controls then pass to the action 1.1 for fetching the first instruction of a supervisory program for interruption handling (IH).

The embodiment hinges on the engineering into the apparatus of a native branch instruction (TPI) intended to -be used to initiate recursive action within interruption handling programs of such environmental systems. As shown in Fig. 2 the TPI instruction (indicated at 2.1) contains an eight-bit operation code (OP Code) shown at 2.1.1 and an eight-bit field 2.1.2 which is either unused or may be used as described below to distinguish the class of interruption requests which may be "tested" by the instruction. The system sequence controls 2.2. for decoding instructions are provided with an extra decoding point 2.2.1 uniquely associated with the TPI instruction.

As indicated in Fig. 2 with the exception of line 2.2.1 (and the code recognition logic associated with said line) the controls 2.2 are essentially identical with the controls 1.2 of Fig. 1 and in response to OP Codes other than that at 2.1.1 provide outputs -to the "normal" execution controls 1.3 of Fig. 1.

With the marking of TPI line 2.2.1 action is taken to determine the class of interruptions associated with the interruption handling program containing the TPI instruction which has just been decoded. The logic for making this determination is indicated schematically at 2.3 and 2.4 in Fig. 2. Class information distinguishing the class of interruption currently being handled (e.g. I/O interruption, external interruption, program interruption, etc.) may be used to enable corresponding AND circuits (2.3.1 for I/O interruption, 2.3.2- for external interruption, 2.3.3. for program interruption, etc.), one of which is thereby prepared to produce output excitation when line 2.2.1 is excited. The class information may be prepared in a register by the program. As an alternative the operation code 2.1.1 of the instruction may be used to distinguish class by having a different operation code for each class. Another alternative would be to use space 2.1.2 of the instruction to distinguish the class. Furthermore it should be obvious that if the TPI instruction were to be employed only relative to one class (e.g.

I/O interruptions) then the foregoing class distinction would not be required and the logic indicated at 2.3. and 2.4 would not be required.

Taking the class of I/O interruptions as representative the action of execution of the associated TPI instruction proceeds as follows (after action 2.3.1). At-2.5 the execution sequence controls determine whether an interruption in the respective class (i.e..I/O interruption class) is pending currently. Obviously this action is a subset of the action shown at 1.4.2 in Fig. 1 and may be adapted in the environmental system using a subset of the associated logic. If no active request is pending in the associated class the condition code is set to 0 as shown at 2.6 and the execution sequence terminates at 2.7 with the usual terminal operation of instruction execution (END OP); i.e. the point 1.3.2 in Fig. 1 at which the controls pass to the action 1.4 for general acceptance of unscheduled - interruption in non-specific classes.

On the other hand if at test 2.5 an active interruption request is pending in the associated class the controls for executing the TPI instruction perform operations 2.8 consisting of the setting of the condition code to state 1(2.8.1), selection of one active request in the specific class (I/O Interruption) according to a predetermined priority schedule (2.8.2), the clearance of the selected request (2.8.3) and the storage of the interruption code associated with the selected request (2.8.4). The actions of request selection, request clearance and interruption code storage constitute a subset of the actions shown at 1.4.3. in Fig. 1 (excluding the PSW exchange) and may be implemented by similar logic or by using the existing logic associated with actions 1.4.3 through re-entrant microprogramming.

Upon completing the actions 2.8 the controls pass via terminal operation 2.7/1.3.2 (END OP) to the conventional sequence 1.4 for conditional acceptance of interruptions in nonspecific classes.

The application of the TPI instruction in a supervisory program for handling I/O interruption is indicated in Fig. 3. A comparative presentation of prior art recursive handling is presented in Fig. 4. An arbitrary program X (shown at 3.1 in Fig. 3 and 4.1 in Fig. 4) is presumed to be interrupted by acceptance of an I/O interruption request (at 3.2 in Fig. 3; 4.2 in Fig. 4) in accordance with actions 1.4 in Fig. 1. Individual program instruction actions are indicated schematica]ly by horizontal lines; as shown for instance at 3.1.1.

In the initial stage of programmed interruption handling after acceptance (first level interruption handling or FLIH), indicated at 3.3 in Fig. 3 and 4.3 in Fig. 4, the supervisory program for interruption handling determines the cause of interruption and stores any additional environmental information which may be required relative to the further handling of said interruption. In an advanced stage of interruption handling (second level interruption handling or SLIH), shown at 3.4 in Fig. 3 and 4.4 in Fig. 4, the program performs actions required to service the interruption. In the case of I/O interruption such actions may involve for instance storage displacement of channel status word (CSW) information relative to a specific I/O channel.

Instruction 3.4.2 in the second level sequence 3.4 is executed initially later than the first instruction 3.4.1 in the same sequence and represents an initial point of recursive entry uniquely associated with the execution of a TPI instruction as described below. As indicated at 3.5 execution of TPI sets a condition code 0 or 1 as described previously. A branch instruction shown at 3.6 tests this code.

If condition code 0 is set the program is sequenced by the branch instruction to a Load PSW (LPSW) instruction shown at 3.7.

This loads the "old" PSW into the system registers and effectively returns control of the system to the interrupted program (X); at the instruction 3.8 which would have been executed next if interruption had not been accepted at 3.2.

If condition code 1 is set by the TPI instruction branch instruction 3.6 branches the program as suggested at 3.6.1 into its recursive entry point 3.4.2. From this point the program 3.4 proceeds to perform only operations associated with the handling of the interruption request cleared by the TPI execution action as set forth previously. Since the TPI instruction and its associated branch instruction are located at a "final" position in the interruption handling program (just prior to the return of control to the interrupted program X), and since the TPI instruction invariably selects an interruption in the same class as the interruption just handled, it may be appreciated that there is no need to displace status or environmental information upon or in association with TPI execution.

Furthermore since the TPI instruction is provided explicitly at such final position in the interruption handling program the program "knows" implicitly that all actions relative to the handling of the previous interruption have been completed and that the interruption request which must be serviced is identified by the currently stored interruption code (i.e. the code overwritten by TPI execution).

Therefore a status exchange is not required and a minimal program routine may be used to complete the handling of the interruption "taken" by the action of TPI execution.

By way of contrast the first level interruption handling sequence at 4.3 in Fig. 4 includes a preparational subsequence shown at 4.3.1 which is not needed when TPI is used.

The preparational sequence moves the program status information associated with program X temporarily to a backup storage position in anticipation of a further program status exchange described below and further conditions the program to be able to "skip" over unnecessary program steps during recursive interruption handling as described below.

In the second level interruption handling sequence 4.4., at a point 4.4.1 which is reached after all actions relative to the interruption accepted at 4.2 have been performed, the program contains an instruction for setting an enabling bit in the program status word which is currently in control of the system. This enables the system for recursive acceptance of interruption at 4.6 in the class (I/O) associated with the interruption accepted at 4.2. If no requests are pending in said class the program advances to instruction 4.5.1 in segment 4.5 of the second level program for interruption handling. Instruction 4.5.1 resets the enabling bit in the PSW to a disabling condition and the program proceeds at 4.7 to restore the environment which existed in the system prior to the preparational sequence 4.3.1.

When this is accomplished the Load PSW instruction 4.8 is executed to return control to interrupted program X at 4.9.

If an I/O interruption request is accepted at 4.6 the PSW exchange 1.4.3.4 and other actions 1.4 of Fig. 1 are carried out at 4.6.

The "new" PSW contains the address of instruction 4.3.2 entered via recursive entry path 4.6.1 at an initial stage of first level interruption handling program 4.3. By virtue of the preparation performed at 4.3.1 the interruption handling program proceeds to perform the requisite operations but skips many of the steps which are performed ordinarily during a first pass through the program from acceptance stage 4.2. Eventually the program returns to enablement stage 4.4.1 and, if no further interruptions are accepted at 4.6, to the disablement stage 4.5.1. The environmental restoration operations 4.7.1 place the program in the state prior to preparation operations 4.3.1 after which the interrupted program X is returned to control by Load PSW 4.8. Quite clearly considering Figs. 3 and 4 comparatively it becomes evident that with the TPI instruction the program status exchange at 4.6 is avoided and the preparational actions 4.3.1 and restorative actions 4.7.1 may be eliminated thereby short- ening the interruption handling program.

WHAT WE CLAIM IS: 1. Data processing apparatus comprising a hardware/supervisory program combination adapted to service task oriented program routines on a multiprogram interrupt basis, such service including, when an interrupt is accepted during the execution of a routine, storing the task/system profile associated with the interrupted routine, establishing a task/system profile for the interrupting routine, invoking the interrupting routine and exiting via a branch instruction which causes the testing of pending interrupts, if any, to detect if an interrupt of the same class is pending and branches either to the invoking entry point in the supervisory program bypassing any task/system profile storing and establishing if a pending interrupt, which is of the same class as the interrupting routine and requires no task/system profile change, is detected, thus causing execution of all such pending interrupts before return to the interrupted routine, or to a restoring routine for the interrupted task program if no interrupt of the same class is pending.

2. Apparatus as claimed in claim 1 programmed to perform 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 upon having distingu shed pendency of at least one said request, storing interruption code information identifying the source of said conditionally terminated request, and disabling the apparatus 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.

3. Data processing apparatus substantially as hereinbefore described with reference to and as illustrated in Figs. 2 and 3 of the accompanying drawings.

**WARNING** end of DESC field may overlap start of CLMS **.

Claims (3)

**WARNING** start of CLMS field may overlap end of DESC **. If an I/O interruption request is accepted at 4.6 the PSW exchange 1.4.3.4 and other actions 1.4 of Fig. 1 are carried out at 4.6. The "new" PSW contains the address of instruction 4.3.2 entered via recursive entry path 4.6.1 at an initial stage of first level interruption handling program 4.3. By virtue of the preparation performed at 4.3.1 the interruption handling program proceeds to perform the requisite operations but skips many of the steps which are performed ordinarily during a first pass through the program from acceptance stage 4.2. Eventually the program returns to enablement stage 4.4.1 and, if no further interruptions are accepted at 4.6, to the disablement stage 4.5.1. The environmental restoration operations 4.7.1 place the program in the state prior to preparation operations 4.3.1 after which the interrupted program X is returned to control by Load PSW 4.8. Quite clearly considering Figs. 3 and 4 comparatively it becomes evident that with the TPI instruction the program status exchange at 4.6 is avoided and the preparational actions 4.3.1 and restorative actions 4.7.1 may be eliminated thereby short- ening the interruption handling program. WHAT WE CLAIM IS:

1. Data processing apparatus comprising a hardware/supervisory program combination adapted to service task oriented program routines on a multiprogram interrupt basis, such service including, when an interrupt is accepted during the execution of a routine, storing the task/system profile associated with the interrupted routine, establishing a task/system profile for the interrupting routine, invoking the interrupting routine and exiting via a branch instruction which causes the testing of pending interrupts, if any, to detect if an interrupt of the same class is pending and branches either to the invoking entry point in the supervisory program bypassing any task/system profile storing and establishing if a pending interrupt, which is of the same class as the interrupting routine and requires no task/system profile change, is detected, thus causing execution of all such pending interrupts before return to the interrupted routine, or to a restoring routine for the interrupted task program if no interrupt of the same class is pending.

2. Apparatus as claimed in claim 1 programmed to perform 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 upon having distingu shed pendency of at least one said request, storing interruption code information identifying the source of said conditionally terminated request, and disabling the apparatus 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.

3. Data processing apparatus substantially as hereinbefore described with reference to and as illustrated in Figs. 2 and 3 of the accompanying drawings.