I assigned the innovation of interrupt vectors to the Lincoln Labs
TX-2 based on Jim Forgie's February 1957 paper. A case can be made
for tracing this innovation to the work by Dick Turner and Joe Rawlings
on the NACA Lewis Lab Univac 1103 (reported in March 1957 and June 1958
papers) as well as to Fred Brooks' work on an interrupt system for the
IBM Stretch (reported in December 1957 paper and patent application).

I assigned the innovation of DMA to the IBM SAGE, but I am unable
to date its use in SAGE to earlier than the publication of the concept
in the 1954 DYSEAC papers. DYSEAC thus seems to be the first design
to use DMA.

The latter citations refer to an interrupt system that was
developed by NACA employees Dick Turner and Joe Rawlings in late
1955 and first operational in February 1956. Univac provided
a version of this interrupt scheme to customers as a feature
of the model "1103A".

The work on the interrupt system for the 1103 took place at
the NACA Lewis Flight Propulsion Laboratory in Cleveland, Ohio.
(The lab is now known as the NASA John Glenn Research Center at
Lewis Field.) The 1103 was normally used for batch processing
but was modified so that it could be interrupted to start
collecting real-time wind tunnel data.

(thanks to Eugene Pallat and David Hemmendinger)
L. Richard Turner and Joseph H. Rawlings documented their work
on the 1103 at Lewis in
"Realization of Randomly Timed Computer Input and Output by
Means of an Interrupt Feature,"
IRE Transactions on Electronic Computers, EC-7, 2, June 1958,
pp. 141-149 (the paper notes that the material was first
presented at the Symposium on Computers in Simulation, Data
Reduction, and Control in March 1957). They state that the
interrupt system was put into operation in February 1956.
Turner was the Chief of the Mechanized Computation and Analysis
Branch at Lewis at the time of publication, and Rawlings was
Head of Computer Engineering at Lewis. The paper discusses
multiple I/O devices with multiple respective service
subroutines. It describes a "pluggable COMMAND EMITTER having
a position available for each device." While the 1103A produced
and sold by Univac appears to lack this "emitter" and relies
instead on a single fixed memory location, the scheme described
by Turner and Rawlings provides vectored interrupts.

(thanks to George Gray and Eugene Pallat)
"The 1103 at NACA in Cleveland was ordered June 15, 1954.
Passage of the acceptance test was ... in September 1955.
It was the seventh 1103 built and the second one (in the
commercial side) to have core memory." [The January 2002
Unisys History Newsletter lists the first five 1103 customers.
These first five machines had electrostatic memory, which proved
unreliable. Later customers received core-memory 1103s, which
started delivery in November 1954.]
However, Eugene Pallat, who worked on the 1103 at Lewis, states,
"After the computer was phased out and replaced, I removed the
ID plate from the core box. On it was engraved 'Serial Number 1.'"

Univac incorporated the interrupt idea into a revised
core-memory production model (4,096 words) and marketed the system
as the
1103A.

(thanks to David Hemmendinger)
See "The Univac Scientific Program Interrupt,"
pages 18-21 within
The Univac Scientific General Purpose Computer System
(Model 1103 A), Preliminary Information, December 1955.
The 1103A had one program counter (PAK), and, upon an interrupt,
the next instruction was taken from memory location 2. This
location typically held a Return Jump instruction so that the
updated value of the program counter (i.e., the return address)
would be stored into the address field of a jump instruction in
a specified memory location (typically at the end of the interrupt
service subroutine) and the program counter would then be loaded
with the address of the interrupt service subroutine.
The first 1103A computers were delivered in late 1956.

Arithmetic overflow either triggered the execution a
two-instruction fix-up routine at address 0, or, at the
programmer's option, caused the computer to stop.

From 1953 programming manual, p. 83:

The computer reacts to an "overflow" situation automatically. The
sequence of instructions is interrupted, and the pair of instructions
in memory location 000 is inserted. This insertion is effected after
both instructions of the original pair have been executed even though
overflow may have been caused by the first instruction of the pair.

If memory location 000 contains an instruction which transfers
control, a new sequence is initiated. It is important to note that,
if no transfer of control is ordered, the original sequence of
instructions is resumed after executing the pair contained in 000.

The inserted instructions were often used by programmers for
looping.

(cf. SWAC with a 4th address in the instruction used to specify a
branch address on overflow)

Note a claim that the Cambridge University
EDSAC had interrupts in the early 1950s; however, after investigating,
it appears to me that they are using this term for periodic polling in
which explicit conditional branches must be inserted into the program.

The 650 had a console option to automatically branch to a restart
sequence upon a machine error.

Blaauw and Brooks write:

There is a rudimentary interrupt system for machine errors. When the
stop condition of the Machine Error indicator in [sic] not enabled by
its mask switch, it causes a trap. The next instruction is now taken
from the console switches, word 8000, instead of from the specified
location. There is no status preservation whatever; there is no way
to know where the offending trap occurred. Moreover, the Distributor
and Accumulator are reset; the main purpose is to get a fresh restart
after an intermittent error.

Note that a 650-like machine is described in U.S. Patent 3,017,092,
which was filed by IBM Endicott inventors in September 1957, was
granted in January 1962, and which records claims for a single-level
interrupt system.

DYSEAC had two program counters, and an I/O signal caused execution
to switch from one PC to the other. A bit in each instruction
indicates which PC to use for the next instruction.

The DYSEAC was delivered to the Army in 1954, and papers describing
the DYSEAC were published that same year. Since this is a year before
the likely time of development of the interrupt system on the Lewis
Univac 1103 (see above), I would assign the distinction of being the
first computer to use I/O interrupts to the DYSEAC.

In the context of arithmetic overflow handling in the UNIVAC I,
Codd states,
"in the NBS DYSEAC the very significant step was made of
extending interruption to input-output operations."
[E.F. Codd, "Multiprogramming," pp. 77-153, in F.L. Alt and
M. Rubinoff (eds.), Advances in Computers, Vol. 3. New York:
Academic Press, 1962.]

The DYSEAC also appears to be the first computer to provide DMA,
although IBM was granted a patent for DMA cycle-stealing on the
SAGE system (US 3,319,230 Astrahan, et al., "Data Processing Machine
Including Program Interrupt Feature," filed Sept. 1956 and granted
May 1967). (The SAGE project started in 1952, and I cannot yet
determine the date of the first use of DMA in the design.)

Each input-output instruction ... indicates whether or not a
Program-Jump operation is desired after completion of the
input-output operation. If a Program-Jump is desired, then a
signal is produced after the input-output operation is completed
which causes the program to jump, i.e., the counter-register being
used as the source of the next instruction is temporarily
abandoned, and the instruction word in the address specified by
the other counter-register is executed in its stead. ...
After effecting a program-jump, the new program that is initiated
may, as soon as its final instruction is performed, cause the
machine to resume the interrupted program where it left off, if
the programmer so desires.

...

It might be noted again that any consecutive areas of the memory in
DYSEAC, ranging in size from a single word to the entire memory, can
be loaded or printed out even while a program of computation is
proceeding. Automatic interlocks are provided to guard against
inadvertent attempts to use a memory location for conflicting
purposes. For example, if a print-out order is given, the machine
is automatically prevented from writing into any memory location
affected by the print-out order until the word in that location
has been printed out.

...

The Concurrent Input-Output Control has the function of regulating
the detailed progress of all input-output operations requested in
the course of the internal program. It directs the flow of traffic
between the memory and the Input-Output Buffer, ....
It receives signals from the Input-Output Buffer as each complete
word is transferred, and it not only keeps count of the total number
of words handled, but also keeps track of which address in the
high-speed memory contains the word currently to be transferred.
This information is transmitted to the Memory Address Switches at
the proper time.

In the comparatively unlikely event that both the Input-Output Buffer
and some internal unit should simultaneously demand access to the
high-speed memory, the Concurrent Input-Output Control resolves the
conflict by according temporary priority to the external operation.
Likewise it referees conflicts or inconsistencies between the internal
program and the progress of external operations. It also notifies the
Program Control unit at the termination of an input-output operation
so that the program-jump may take place.

For example, if the programmer directs that a given section of the
memory be loaded from an external input unit and then some time
afterwards directs that the contents of a memory location in this
section be used as the source of an instruction, the program will
automatically be temporarily halted until the sought-for memory
location has actually received the word intended for it from the
input unit.

magnetic tapes (several sequences, also one sequence needed
per transfer direction, that is, a read sequence for a given tape
is separate from the write sequence for that tape)

printer

ADC

paper tape readers (several sequences)

light pen

display (several sequences)

MTC

TX-0

DAC

paper tape punch

flexowriters (several sequences)

three main sequences

Thus the assigned priority levels are not under program control and
cannot change during execution.

Each instruction has break and dismiss bits: break is used to
indicate points at which a higher-priority sequence can take over,
while dismiss is used to end the current sequence and allow
lower-priority sequences to resume. Deferred breaks can thus
be used to disable nested interrupts during a critical section
(in which information used by the current sequence could be
corrupted by a higher-priority sequence, should it be allowed
to break in and execute).

One of the I/O instructions, ios, can be used by the restart
sequence (or actually by any sequence) to send attention and
dismiss bits to the sequence selection logic of any priority
level.

Carl Ellison:
"If you asked for data in and there wasn't any,
then your interrupt level was dismissed -- and when data arrived,
you were resumed. Similarly, if you try to output when the
output buffer was full, you dismiss before doing the output and
resume at that level when the buffer empties."

S. Gill, "Parallel Programming," Computer Journal,
Vol. 1, No. 1, April 1958, pp. 2-10.
"However, in the future one
computer in particular will stand out as a classic example of the
wholesale application of the time-sharing technique. This is the
TX-2 computer ... now nearing completion at the Lincoln Laboratory
of the Massachusetts Institute of Technology."

Stretch had a combined approach to interrupts and conditional branching.
There was a single indicator register containing 64 bits, the first 48
bits of which were monitored by the interrupt system. There was also a
28-bit mask register. Of the 64 bits:

28 bits could be masked on or off using the mask register
(e.g., result exceptions)

16 bits were always masked off, and thus had to be tested by explicit
conditional branches (e.g., index and arithmetic results)

Branch-disabled and branch-enabled instructions would disable or
enable the entire interrupt system; these were used when entering
and exiting interrupt handlers.

The interrupt vector was structured to hold one instruction for
each interrupt cause. This instruction could be an immediate fix-up,
such as clearing a register, or it could be a subroutine call to an
appropriate interrupt handler. A leftmost-one circuit was used to
choose the highest priority enabled interrupt condition in the
indicator register.

Stretch was meant for multiprogramming and thus provided an interrupt
address register, which held the base address of the interrupt vector
for the current process. This approach was used instead of a single
global vector since the contents of the vector might have to change
as part of a process switch.

Stretch included a 19-bit interval timer and a 36-bit time clock;
both had 1 msec resolution. The interval timer could be set to
up to 8 minutes before causing an interrupt. Stretch also had a
fixed interval watchdog timer (1 msec) to prevent infinite loops
in indirect addressing and in execute instructions

Stretch provided two forms of execute instructions that would
interrupt when the target instruction was a taken branch; this was
useful for program monitoring. Stretch also provided up to three
programmer-defined data flags (T,U,V) in the extended form of its
"sign byte" for operands. Reading an operand with one of these
bits set would cause an interrupt; this was another useful feature
for program monitoring.

The clever feature was that rather than requiring the processor to use
its precious time, swapping memory in and out of the drum storage space,
the transfers would be automatically done on demand. This was implemented
using another clever technique. If a request was made for data not
currently in the core memory, an interrupt, (then called an extracode
instruction), was called. This paused the execution of the program, and
automatically loaded the page of memory which the data was in, (a page
being a 512 word block of memory).

A further optimisation to this technique was also implemented. Rather
than check for every instruction to ensure it is in core memory, which
would largely waste time, as the sequential nature of instruction reads
means they are more than likely to be in the current page, a different
method was used. They eliminated the check for each instruction, and
instead implemented an exception handler to deal with the error accesses.

After experiencing circuit design problems that forced a project
restart in 1961, Thornton states that "Substantially more parallel
processing and a new I/O scheme were added to the scope of the
design." He describes the parallel processing related to the I/O
as follows:

The logic gate speed of the new silicon gate was about five times faster
than the 1604. We needed a factor of fifteen or twenty to satisfy our
objective and take parallel operation well beyond that discussed at UCLA.
A first step involved total separation of the input/output operation from
the central processing unit (CPU). Such operations would be executed in
ten independent peripheral processing units (PPUs).
...
The CPU was thus free of I/O operations and, in fact, free to be
designed independently. Cray proceeded with the very innovative barrel
PPU design....
...
The 6600 came under severe criticism from time sharing enthusiasts.
Properties of the machine that caused the most concern were the lack of
virtual memory and the lack of interrupts on the PPUs. The CPU, however,
was interruptible using the very fast exchange jump to achieve rapid
switching of jobs. PPUs had to execute polling action to support interactive
terminals. Ultimate, the great power of the machine overcame much of the
opposition.
...
Each PPU independently executed programs for I/O operations and certain
operating system functions. ... Some early problems arose from tyhe fact
that all ten PPUs could be referencing central memory polling tables for
more work, thus blocking CPU memory references.
...
The essential concept of the PPU was to off-load the detailed interaction
with standard peripheral controllers from the CPU. During the course of
executing an application program, any I/O calls were assigned to a
specific PPU. The CPU might continue or might be switched to another job,
but in either case the assigned PPU would execute the I/O function and
report back when complete. Several such PPU operations could be in execution
at once.
...
The isolation of the CPU "behind" central memory from the PPUs and the I/O
was beneficial.

associates of Cray emphasize his desire to make designs simple
and fast

Interrupt versus polling. The opposite philosophy is vividly
summarized in words attributed to Seymour Cray, designer of the 6600:
"Don't tell me about [such events] when I'm doing something else; all I
can do is save them for handling later. Instead you save them. When
I'm ready to handle them, I'll ask."
The implication is that it is more efficient to complete bursts of
CPU work without interpolated task switches than it is to strain to
the utmost to give immediate response to peripheral events.
...
What is unquestionably true is that the supervisor and perhaps the
machines are simpler when synchronzation is done by polling
than when it is done by interruption.

Note that Peter Patton, a principal programmer at Univac in
the early 1960s, stated that Cray would not use interrupts.
See pages 30 and 56 of Patton's
oral history interview at CBI:

I was responsible as principal programmer for the programming aspects
of the fleet test which was done with these computers onboard ship that
had been designed by Seymour Cray. And this machine was the AUSQ-17 and
interrupts were then known. There were machines that had interrupts, but
in the late 50's Seymour Cray wouldn't use them. And so here was the
world's largest real time system, a command and control, tactical combat
system, which did everything with monitored buffering, no interrupts.
... I was involved in the efforts to redo this whole thing, the one thing
we learned on the fleet test, we passed the fleet test and the NTDS system
became, we got an order for it, but we substituted a new computer,
the AUSQ-20, later known as the Univac 1206, which had an interrupt
structure and it had a different quinary factor but it, that machine
was much easier to program the system.

But also note that between the AUSQ-17 and the 6600, Cray designed
the CDC 1604, which had interrupts. Norm Hardy writes about the 1604:

The machine supported interrupts with the following wart: Upon interrupt
the hardware reported the address of the instruction being interrupted.
That address identified only the word holding the instruction. The hardware
remembered whether the first instruction of that word had been executed.
This memory was inaccessible except to the mechanism that resumed after
interrupts. This made nested interrupts or switching contexts upon interrupt
excessively arcane. This is about the only Cray wart that I recall.

The CDC 7600 introduced an I/O multiplexer with 15 channels.
Each channel had an input bufffer and an output buffer, and
the central processor would be interrupted when a buffer
passed a specified threshold. In the CDC 7600 the operating
system ran on the central processor rather than on a PPU.
(Note that there was a hardware option for the CDC 6600 that
also enabled the OS to run on the central processor.)

In this connection the history of the real-time interrupt is
illuminating. This was an invention from the second half of the 50s,
which enabled the completion of a communication with the external
world to interrupt the execution of one program in favour of another.
It's advantage was that it enabled the implementation of rapid
reaction to changed external circumstances without paying the price
of a lot of processor time lost in unproductive waiting. The
disadvantage was that the operating system had to ensure correct
execution of the various computations despite the unpredictability
of the moments at which the interrupts would take place and the
central processor would be switched from one computation to another;
the nondeterminism implied by this unpredictability has caused
endless headaches for those operating system designers that did
not know how to cope with it. We have seen two reactions to the
challenge of this added complexity.

The one reaction was to enhance the debugging facilities, as IBM
did for the design of OS/360. (This was the operating system IBM
tried to design for its 360-Series of machines, which were introduced
in the first half of the 60s; IBM's problems with this design
facilitated in 1968 the recognition of the world-wide phenomenon
that became known as "the software crisis".) IBM built, in fact,
special-purpose monitors that exactly recorded when the central
processor honoured which interrupt; when something had gone wrong,
the monitor could be turned into a controller, thus forcing a
replay of the suspect history and making the "experiment" repeatable.

The other reaction could be observed at the THE (Technological
University Eindhoven), viz. to determine the conditions under which
one could feasibly and safely reason about such nondeterministic
programs and subsequently to see to it that these conditions were
met by hardware and software.

The difference was striking, showing once more that debugging is
no alternative for intellectual control. While OS/360 remained a
mess forever after, the Multiprogramming System designed at the
THE was so robust that no system malfunction ever gave rise to a
spurious call for hardware maintenance. Needless to say, the whole
episode has made a lasting impression on me.

One moral is that the real-time interrupt was only the wave,
whereas the tide was the introduction of nondeterminism and the
development of the mathematical techniques to cope with it.

The third arrangement, known as "the interrupt", circumvents all
these dilemmas. While the computer calculates at full speed, a
piece of dedicated hardware monitors the outside world for
completion signals from communication devices. When a completion
is detected, the program under execution is interrupted after the
current instruction and in such a fashion that it can be resumed
at a later moment as if nothing had happened, thus instantaneously
freeing the central processor for a suddenly more urgent task.
After the interrupt the processor would execute a standard program
establishing the source of the interruption and taking appropriate action.

It was a great invention, but also a Box of Pandora. Because the
exact moments of the interrupts were unpredictable and outside our
control, the interrupt mechanism turned the computer into a
nondeterministic machine with a nonreproducible behavior, and
could we control such a beast?

In the mean time a pattern emerged for the cooperation between me
and my hardware colleagues Bram J. Loopstra and Carel S Scholten.
After the functional specification of the next machine had been
written down (usually by me), that document served as a kind of
contract between us: it told them what machine to design and
construct, while I knew what I could count upon while writing
all the basic software for the machine. The target of this
division of labour was that my programs would be ready by the
time the construction of the machine had been completed.

Looking back I now observe that the above arrangement has had
a profound influence on how I grew up as programmer: I found it
perfectly normal to program for not yet existing machines. As a
byproduct it became firmly ingrained in my mind that I programmed
for the abstract machine as specified in the original document,
and not for the actual piece of hardware: the original document
was not a description but a prescription, and in the case of a
discrepancy not the text but the actual hardware would be at fault.
...
Of course I could not exclude from my designs typographical errors
and similar blemishes, but such shortcomings did not matter as long
as the machine was not ready yet, and after the completion of the
machine they could be readily identified as soon as they manifested
themselves, but this last comforting thought was denied to me in 1957
with the introduction of the real-time interrupt. When Loopstra and
Scholten suggested this feature for the X1, our next machine, I got
visions of my program causing irreproducible errors and I panicked.

Eventually, Loopstra and Scholten flattered me out of my resistance
and I studied their proposal. The first thing I investigated was
whether I could demonstrate that the machine state could be saved
and restored in such a way that interrupted programs could be
continued as if nothing had happened. I demonstrated instead that
it could not be done and my friends had to change their proposal.
Admittedly the scenarios under which the original proposal would
fail were very unlikely, but this can have only strengthened my
conviction that I had to rely an arguments rather than on experiments.
At the time that conviction was apparently not so widespread, for
up to seven years later I would find flaws in the interrupt hardware
of new commercial machines.

Interrupt system is at a low kernel level, just above the procedure
mechanism.

The interrupt vector, which points to the routines for handling each type
of exception, should encode not only the handler entry points, but their
proper supervisor state and interrupt mask settings. The procedure
mechanism should set the specified supervisor state and masks on call,
and restore them on return.

Hardware condition detectors notify the dispatcher of faults and external
device signals. The detectors for faults could generally be synchronized
with the system clock but the detectors for external conditions could not.

Failure to realize that external condition signals could occur
simultaneously led to interrupt dispatchers prone to arbitration failures.

[Are] interruptions [handled] immediately or is the handling deferred?

[W]hat is the moment of the creation of deferred handlers [or
the data structures required for deferred handling]?
Are they created at boot time or on demand?

[I]s the deferred handling conducted prior to scheduling
or is it subject to scheduling?

Does the [handling] possess the property of priority compliance
[with the hardware interrupt priority]?

For example, in RSX-11M, interrupt handlers that will run more than
500 microseconds and/or will update a system data structure should
fork a routine for later execution by adding a four-word fork block
to a FIFO fork queue. The fork routines must be executed before any
user processes are scheduled. So, in the above categorization, some
of the interupt handling in RSX-11M is deferred, on demand, conducted
prior to scheduling, and does not possess priority compliance.

Koenen-Dresp noted that modern operating systems such as Linux are
typically hybrid designs with some amount of immediate interrupt
handling (e.g., timer interrupts and interprocessor interrupts)
and some amount of deferred interrupt handling.

The motivations for deferred interrupts include:

run the more-involved handling with interrupts re-enabled (e.g.,
when the handling may be lengthy or non-deterministic, and when the
handling could block; see the
reasons for deferred interrupt handling given by the designers
of FreeRTOS)

serialize handler access to kernel data structures
in a uniprocessor (using a special queue of deferred handler tasks)

allow the later invocation a non-resident system routine as
part of the interrupt handling (sometimes called second-level
interrupt handlers)

Mercury Programming System

In
"JN: An Operating System for an Embedded Java Network Computer,"
UCSC-CRL-96-29, 1996, Bruce Montague writes that the idea of deferred
interrupt handling appears to date from at least 1960 with the soft
real-time monitor developed by IBM for the Project Mercury space program.
While it is likely that the idea developed independently a number of
times, he identifies two other IBM systems that were influenced by the
the Mercury Programming System:

all trap processors and queue processors exit through the
sequence control processor, which branches to the highest-priority
queue processor that is available and has a request; once there
are no queue processors remaining that need to be executed, control
returns to the interrupted program

IBM Time Sharing System (TSS) (released as a product in 1967),
running on an IBM S/360 Model 67

Alexander Lett and William Konigsford, "TSS/360: A Time-Shared
Operating System," in Proc. AFIPS FJCC, Part I, San Francisco,
December 1968, pp. 15-28.

TSS was designed to run on a multiprocessor and is
hybrid system in which some interrupts, such as machine check,
write direct (for interprocessor communication), and certain SVC
(supervisor call) instructions, are immediately handled while others,
such as I/O interrupts, are enqueued on a scan table

queue scanner structure for both the resident supervisor (i.e.,
the OS kernel) and a task monitor that runs within the virtual
memory environment of each task

interrupt queueing performed by system component called the
"interrupt stacker"

explicit acknowledgement of design influence from earlier IBM TSM
system

program logic manuals for system logic, resident supervisor, and
task monitor are available at bitsavers in pdf/ibm/360/tss directory

TSS/370 source code (in assembly language) is available at
ibiblio.org (see also the TSS System Programmers Guide in the
collection of manuals for descriptions of the system macros)

Manchester Atlas Supervisor

The Manchester Atlas supervisor is described in
T. Kilburn, R.B. Payne, and D.J. Howarth, "The Atlas Supervisor,"
in Proc. AFIPS EJCC, 1961, pp. 279-294. The supervisor allowed interrupt
handlers to invoke routines within the supervisor for lengthy operations.
These routines ran with interrupts enabled but at a higher priority than
user programs:

The interrupt routines are designed to handle calls for action with
the minimum delay and in the shortest time; the character-by-character
transfers to and from peripheral equipments, for example, occur at high
frequency and it is essential that the transfers be carried out with the
minimum possible use of the central computer and within the time limit
allowed by the peripheral equipment for filling or emptying the buffer.
Since several interrupt flip-flops can become set simultaneously, but
cannot be acted upon while another interrupt routine is still in progress,
it is essential that a short time limit be observed by each interrupt
routine. On some occasions, however, longer sequences are required ...
In such cases, the interrupt routine initiates a routine to be obeyed
under extracode control, known as a supervisor extra code routine.

Supervisor extracode routines (S.E.R.'s) form the principal "branches"
of the supervisor program. They are activated either by interrupt routines
or by extracode instructions occurring in an object program.
...
They can moreover be interrupted by interrupt routines, which may in
turn initiate other S.E.R.'s. It is thus possible for several S.E.R.'s
to be activated at the same time, in the same way as it is possible for
several interrupt flip-flops to be set at the same time. Although several
S.E.R.'s may be activated, obviously not more than one can be obeyed at
any one moment; the rest are either halted or held awaiting execution.
This matter is organized by a part of the supervisor called the
"co-ordinator routine" which is held in fixed store. Activation of an
S.E.R. always occurs via the co-ordinator routine, which arranges that
any S.E.R. in progress is not interrupted by other S.E.R.'s. As these
are activated, they are recorded in subsidary store in lists and an
entry is extracted from one of these lists whenever an S.E.R. ends or
halts itself. Once started, an S.E.R. is always allowed to continue
if it can; a high priority S.E.R. does not "interrupt" a low priority
S.E.R. but is entered only on conclusion or halting of the current S.E.R.
The co-ordinator has the role of the program equivalent of the "inhibit
interrupt flip-flop", the lists of activated S.E.R.'s being the equivalent
of the setting of several interrupt flip-flops. The two major differences
are that no time limit is placed on an S.E.R., and that an S.E.R. may halt
itself for various reasons; this is in contrast to interrupt routines,
which observe a time limit and are never halted.
...
In order that the activity of each branch of the computing system be
maintained at the highest possible level, the S.E.R.'s awaiting
execution are recorded in four distinct lists. Within each list, the
routines are obeyed in the order in which they were activated, but the
lists are assigned priorities, so that the top priority list is emptied
before entries are extracted from the next list. The top priority list
holds routines initiated by completion of drum transfers, and also
routines entered as a result of computer failures such as core store
parity. The second list holds routines arising from magnetic tape
interruptions and the third holds routines arising from peripheral
interruptions. The lowest priority list contains one entry for each
object program currently under execution, and entry to an S.E.R. through
an extracode instruction in an object program is recorded in this list.
On completion of an S.E.R., the co-ordinator routine selects for execution
the first activated S.E.R. in the highest priority list.

SDS Sigma-7

Two systems with deferred handling are cited by Richard Watson in
Timesharing System Design Concepts, 1970:

the reference to the XDS-940 ability to trigger a lower-priority
interrupt on p. 126 could be describing the SDS Sigma-7
instead; I could not find a programmable ability to trigger
a hardware interrupt in the 940 reference manual

"The Trigger function permits the CPU to apply an
interrupt signal to its own interrupt system. ...
It also permits the CPU to carry out the highly time
sensitive portion of an interrupt response and then
to create for itself a low priority interrupt to call
for the deferred servicing of the less time sensitive
portion at a less pressing time."

The write direct (WD) instruction is used to trigger
an interrupt.

Sigma-7 reference manuals are available at
bitsavers in pdf/sds/sigma/sigma7 directory

SDS 940 Time Sharing System (ca. 1967), later XDS 940

Project Genie at UC Berkely modified an SDS 930 to
support multi-user time-sharing, and SDS made the
modified computer into a product

terminology uses "forks" instead of "processes" or "threads"

deferred handling is performed by the monitor running as a
"phantom user" and processing tasks enqueued by interrupt
handlers on a "phantom user task queue"

when the phantom user is chosen by the scheduler, it runs
until it empties the queue or until no tasks are left that
can be processed at that point (e.g., a time-out task with
remaining time)

940 timesharing manuals are available at
bitsavers in pdf/sds/9xx/940 directory

p. 144, Multics,
project began in 1965 with multi-process execution achieved in 1968

Multics papers and manuals are available at
multicians.org Bibliography

see forward to Helen Custer book on NT: Cutler writes that he
came to DEC in 1971. "My first operating system project was to
build a real-time system called RSX-11M that ran on Digital's
PDP-11 16-bit series of minicomputers. ... It involved
re-implementing an existing system but allowed us the freedom
to change and subset the programming interfaces as long as
programs could be reassembled or recompiled with minimal
source-code changes. RSX-11M was introduced in 1973, 18 months
after we started building it."

regarding prior versions of RSX-11:
RSX-15, designed by Dennis Brevik, did not have fork routines;
and, Brevik describes RSX-11D as a reimplementation of RSX-15
for the PDP-11 done by Hank Krejci

DEC VMS (1977), running on DEC VAX-11/780

Culter, Dick Hustvedt, and Peter Lipman were the three principal
designers of VMS
(Sergey Oboguev lists their respective areas of responsibility
in a
2015 SIMH mailing list posting)

deferred handlers called fork processes

DEC Mica (cancelled in 1988), to run on DEC PRSIM

Mica documents are available at
bitsavers in pdf/dec/prism/mica directory,
but none appear to describe deferred handling

see J.E. Smith and A.R. Pleszkun, "Implementation of Precise
Interrupts in Pipelined Processors," in Proc. ISCA, June 1985

a hardware facility such as a reorder buffer can also be used
for branch misprediction recovery; see
G.S. Sohi and S. Vajapeyam, "Instruction Issue Logic for
High-Performance, Interruptable Pipelined Computers,"
in Proc. ISCA, June 1987

see also Mayan Moudgill and Stamatis Vassiliadis,
"Precise Interrupts," IEEE Micro, February 1996