The Interrupt
Every other machine here does one thing after another. This is the one that stops.
The processor
1 Raise: a line goes high while the processor is in the middle of something
2 Finish: the instruction in flight completes, because half an instruction is not a state
3 Save: the program counter and the flags go somewhere they can be found again
4 Vector: a fixed address says where to go, and the return is the part people get wrong
Uninterrupted, this program reports 18. Interrupt it and see whether it still does.
Checked when this page loaded: an interrupt was fired after each of 12 instruction boundaries. With the handler saving the accumulator, 0 of them changed the answer. With it not saving, 4 did.
Before this, a machine had to ask
A computer that cannot be interrupted has one way to find out whether anything has happened: ask. Ask the reader whether a card is ready, ask the printer whether it wants another line, ask again, forever, in between doing the work you actually wanted. Everything runs at the speed of the asking, and the asking never stops.
An interrupt turns that around. The device raises a line, and the processor leaves what it was doing and goes to deal with it. Nothing has to be asked, and nothing has to be anticipated.
Four things have to be true
The first is that the instruction already running finishes. There is no stopping half way through one, because half an instruction is not a state anything could be restored to.
The second is that the address saved is the next instruction rather than the one that just ran, or the return would do the same work twice.
The third is that the hardware knows where the handler is without being told each time, which is what a vector is: one fixed address the processor jumps to, needing no agreement with the program about anything else.
The fourth is that everything the handler disturbs is put back. That is the one that gets missed, and the machine above lets you miss it.
The bug that does not look like one
Turn off the handler's save and interrupt the program. Nothing crashes. Nothing is flagged. The program runs to the end and reports a number, and the number is wrong, because the handler used the accumulator for its own work and never put back what was in it.
That is what makes interrupt bugs the shape they are. The interrupted program is correct, the handler is correct on its own, and the fault only exists in the moment where one is inside the other. The page fires an interrupt after every instruction boundary when it loads and reports how many of them change the answer, both ways, rather than asking you to take that paragraph on trust.
Who was first depends on what you mean
Interrupts are usually dated to 1953 and the UNIVAC 1103. That date does not survive being looked at: the 1953 machine's manual does not describe interrupts at all, and the interrupt system attached to one was built by Dick Turner and Joe Rawlings at NACA in late 1955, first working in February 1956.
The DYSEAC, delivered to the Army in 1954 and written up the same year, is the earliest machine that can fairly be said to have taken interrupts from input and output. So 1954 is the date on this page.
Though even that hides something. The first interrupts were not for devices at all. They were for exceptions — the UNIVAC I in 1951 could take an arithmetic overflow and jump somewhere — and the idea was only later pointed at I/O. An interrupt started life as a way of handling a mistake.
What is real here, and what is not
This is not a processor
Eight opcodes, one accumulator, one stack, no pipeline, no cycles, no memory to speak of. A real machine has priorities, several vectors, nesting, and a great deal of argument about what happens when two lines go high at once. None of that is here.
The date is contested and the common one is wrong
1953 and the UNIVAC 1103 is the answer you will usually be given, and the 1953 manual does not mention interrupts. This page follows Mark Smotherman's account, which puts the 1103's interrupt system at February 1956 and gives the earliest I/O interrupts to the DYSEAC in 1954. If you want a single year, 1954 is the defensible one, and the honest answer is that it depends what you count.
Nothing here is timed
Interrupt latency is most of what matters about interrupts in practice, and there is none of it here: no cycle counts, no worst case, no measurement of how long the handler takes or what that costs the thing it interrupted.
Saving one register is a stand-in for saving the machine
The handler here disturbs the accumulator and puts it back. A real one has to preserve every register and every flag it touches, which on some machines is most of the processor and is why hardware often does part of it for you.