# How are interrupts handled?

Andrew S. Tanenbaum, in his book Modern Operating Systems, states that

Once the CPU has decided to take the interrupt, the program counter and PSW are typically then pushed onto the current stack and the CPU switched into kernel mode.

Once the interrupt handler (part of the driver for the interrupting device) has started, it removes the stacked program counter and PSW and saves them, then queries the device to learn its status.

I am not able to understand, why the CPU first stores the registers in the stack and then later the interrupt handler saves them in the Process Table. Wouldn't it be better if it could directly save the current registers in the Process Table without pushing them into the stack?

• Good answer but I don' even think that a modern os will actually save anything in the process table. I think most os have a per process kernel stack. They simply leave the data there until they return to that process later (allowing the use of specialized return instructions i.e. iret for x86). Apr 21 at 7:55
• Yes this is architecture (and os) specific. I think the book is being overly general including every "modern os". In the case of x86 (that MacOS was running on before), when I think of it more I think that the os doesn't even have the choice to use IRET. The problem is mostly with setting CS and FLAGS. Even RIP cannot be set without side effects like pushing something new on the stack (with call or wtv). I don't have the big picture but I think the data/registers that need to be switched should just remain on a small per thread kernel stack. Apr 21 at 14:17