How does interrupt differ from subroutine calls?

Question

A subroutine is called by a program instruction to perform a function needed by the calling program. While Interrupt is initiated by an event such as an input operation or a hardware error. But how does the processor differentiate between them?

Answer 1

To add to the other good answers, I'm going to speak more to the logical similarities of function calling vs. interrupts, and then how those differ as well.

From a logical perspective, a subroutine or function call suspends the currently executing caller and transfers control to the sub/func.  When that sub/func is finished, it returns control to the caller and it resumes after the call it made.

That is from a logical perspective — however, as far as the hardware is concerned there is no suspension or resumption or transfer of control from caller to callee — there is just a continuous execution stream of machine code instructions that happens to include various kinds of branching instructions, like call (jal e.g. on MIPS) and ret (jr)

The transfer of control from caller to callee happens under very controlled circumstances — a lot of this by software agreement, the ABI and the calling convention specified in the ABI.  Caller and callee, by software convention have agreed in advance how parameters are passed, return values transferred back, and what registers are free for the callee to clobber vs. what register that, if used, it must preserve/restore upon return.  Transfers of control from caller to callee happen at call sites and return sites, which are under program control — they happen synchronously as the result of executing instructions of the program.

---

When an interrupt happens, it could happen as if between any two instructions — so for one, there is no "calling convention" to govern the transfer from, say, user code (what is being interrupted) to the exception handler.  With regard to external interrupts, the exception handler doesn't fully understand the code that was interrupted (the interrupted code is not attempting to make a synchronous call to the operating system).  In this situation, all processor state such as registers must be presumed to be busy/in-use in the interrupted code, which has basically been forcefully suspended by transferring control to the exception handler.

External interrupts don't return values to the code that was interrupted — they change operating system state (device status), which may make some other process(es) go from blocked to runnable.

Because external interrupt may occur between any two instructions (unlike calls where the software can see the points of suspension/resumption), in order to make the thread resumable, (compared with function calls) more processor state needs to be preserved just in case the interrupted thread should later be read that state.

Even though modern hardware has many instructions in flight at any point in time, it has to preserve the illusion that the interrupt occurred in between two (dynamically) adjacent instructions.  In part, this is so that it can indicate the program counter / instruction pointer within the interrupted program, of where to resume it.

As a result of external interrupts, the operating system's state changes.  As a result of these changes, the operating system, upon returning from interrupt, may choose to resume a different thread than the one interrupted (in another process even), leaving the interrupted thread in a suspended state for later resumption.  In this manner, scheduling and interleaving of threads may occur, which is substantially different (logically speaking) from function calling and function returning to caller.  (Some user level systems have coroutines and fibers which exhibit transfer of control other than from caller to callee and back.)

In summary, function calling is done under control of the program, only at controlled points, and facilitated by software calling conventions and certain user-mode call and return instructions.  However, to be clear, calling and returning can be done without these dedicated call and return instructions (they can be simulated by alternative instruction sequences without difficulty).  Whereas external interrupts are triggered by an external device signaling the processor, may occur as if between any two instruction in the interrupted code, and in part because they involve privilege changes, requires a privileged instruction to resume from interruption & suspension that would be difficult or impossible to simulate with other, regular instructions.

Answer 2

Obviously running a call instruction invokes completely different behaviour than interrupt handling. (e.g. x86 https://wiki.osdev.org/Interrupts, and When an interrupt occurs, what happens to instructions in the pipeline?). The CPU switches into kernel (supervisor) mode to handle interrupts, on CPUs that have separate privilege levels.

After that, the CPU doesn't care how it got into its current state. The CPU just executes instructions; it's up to the programmer (of the OS or the subroutine) to put useful instructions there, e.g. on x86 ending with ret (normal return) or iret (interrupt-return).

ret is not "special", on x86 it just pops a return address from the stack into the program counter. You can do the same thing other (usually slower) ways. iret also has well-defined behaviour, not magic, and could perhaps be emulated with the right combination of popf and far ref [rsp] or other instructions, or maybe not depending on GDT entries. It's still not magic, though, just an instruction that makes specific changes to the architectural state (e.g. switching back to user mode, out of supervisor mode)

Things are similar on other ISAs; different instruction names, and different ways for the CPU to save enough state for the kernel to be able to return to user-space after interrupts.