IBM Systems 360 Model 91 Imprecise Interrupts

The Model 91 performs all the interruption functions defined for the
IBM System/360. ... The supervisor call, external, machine check, and
I/O interruptions are logically handled as defined. However, the
performance objectives of the Model 91 require some deviations in the
handling of program exceptions. The program-exception deviations are
basically those resulting from an operation that has been sent by the
instruction processor to another element for execution, and the
current PSW no longer references the operation. Consequently, the
interruption-causing instruction cannot be directly identified, and
such a program interruption is described as being imprecise.

[Almost two pages of details follow, including the description of a
no-operation instruction (a particular encoding of the BCR instruction)
that acts as a barrier instruction and causes all previously-decoded
instructions to complete before it can execute. There is a note that
stores can execute out of order and that channel programs may require
the use of the nop-barrier instruction.]

Interrupts, as architecturally constrained, are a major bottleneck to
performance in the assembly line organization. Strict adherence to a
specification which states that an interrupt on instruction n
should logically precede and inhibit any action from being taken on
instruction n + 1 leaves two alternatives. The first would be
to force sequentialism between instructions which may lead to an
interrupt. In view of the variety of interrupt possibilities defined,
this course would totally thwart high performance and is necessarily
discarded. The second is to set aside sufficient information to
permit recovery from any interrupt which might arise. In view of
the pipeline and execution concurrency which allows the Model 91 to
advance many instructions beyond n prior to its execution,
and to execute independent instructions out of sequence (n + m
before n), the recovery problem becomes extremely complex
and costly. Taking this approach would entail hardware additions to
the extent that it would severely degrade the performance one is
seeking to enhance. The impracticality of both alternatives by which
the interrupt specifications could be met made it mandatory that the
specifications themselves be altered. The architecture was compromised
by removing the above-mentioned "precedence" and "inhibit" requirements.
The specification change led to what is termed the "imprecise interrupt"
philosophy of the Model 91 and reduced the interrupt bottleneck to an
instruction supply discontinuity.

Both the 6600 and the Model 91 (and, in certain circumstances, the Model
75) suffer from the "imprecise interrupt" problem. This means that when an
interrupt -- or its equivalent, in the case of the 6600 -- is caused by
execution of an instruction in the program, the location of the particular
instruction causing the interrupt is not indicated precisely. If a jump
instruction intervened, then the location of the offending instruction
is not determined at all. This impreciseness is a consequence of the
parallelism of the arithmetic units of both machines.* Imprecise interrupts
will unquestionably cause difficulty in debugging programs, particularly
system programs.
The Model 91 designers have provided a switch that puts the machine into
non-overlapped mode, in which it runs at about Model 75 speed but with
precise interrupts. This switch will be important for program debugging,
and it can be set and reset by programming.

[footnote as given in report]
* Note: However, it is not a necessary consequence and could have been
eliminated with some extra hardware in the CPU.

[Question from David Gifford] Have architectural deviations
been allowed, to improve performance in a particular model?
[Andris] Padegs Performance normally is not the motivation for a
deviation from architecture. A deviation normally is allowed after
the fact. Furthermore, we do not grant deviations for the basic part
of the architecture that would affect the normal operation of a program.
For example, in the past we have allowed a deviation when the test
light on the panel doesn't come on at the right time. A deviation
normally is requested to avoid the cost of correcting the design.
[Question from David Gifford] Was the imprecise interrupt in
the Model 91 an architectural deviation?
Padegs I guess you would have to call it a deviation, yes.
I look at deviations as minor things that don't affect the basic
functioning of a machine. Normally there are very few deviations in
a machine, perhaps a couple or none at all. Imprecise interrupts in
the Model 61 were a design decision. It was really almost like adding
a new function to the machine. We told the users of that machine that
in exchange for increased performance they could not recover from
floating-point errors.
[Richard] Case Imprecise interrupts did not survive in
the successor to the Model 91, by the way.