1
$\begingroup$

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?

$\endgroup$

1 Answer 1

2
$\begingroup$

This is a matter of abstraction. Details like the process table or where this data is saved are a matter of the design of the operating system. Different operating systems may store this information in a different place, and may have a different mechanism for keeping track of where to save it. Some OS's might not even have a process table at all. So, it doesn't make sense to try to hardcode this into the CPU.

In general, there is a separation of responsibilities between the CPU and the operating system. It wouldn't make sense to try to take everything that is currently done by the operating system and hardcode it into the CPU, because that would limit the flexibility of the OS, and would make the CPU more complex for little gain.

$\endgroup$
6
  • $\begingroup$ 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). $\endgroup$
    – user123
    Apr 21 at 7:55
  • $\begingroup$ @user123, oh, thank you, I didn't realize that. I appreciate your correction. Perhaps you might be interested in writing a better answer? $\endgroup$
    – D.W.
    Apr 21 at 7:56
  • $\begingroup$ I don't have all the details. It just popped in my head thinking there might be some overly general statements in the book that makes things unclear. I hoped you could have those clarifications but I may work on an answer later. $\endgroup$
    – user123
    Apr 21 at 8:11
  • $\begingroup$ @user123 As always, depends. QNX Neutrino, because it's designed for very small embedded systems, maintains one kernel stack per CPU. Mach (and therefore MacOS, iOS, etc) tries to maintain one kernel stack per process (not per thread!). They both, therefore, save user registers to the thread structure. $\endgroup$
    – Pseudonym
    Apr 21 at 8:15
  • $\begingroup$ 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. $\endgroup$
    – user123
    Apr 21 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.