Context switching in function vs interrupt call?

Question

I understand the basic difference between function call & interrupt (ISR) jump from below SE question.

difference between function call & ISR

But I am still not clear about, what are the registers will be pushed /pop to/from stack in both the cases? How context switching will happen in both the case? As we don't know when interrupt will occur, what we need to save (variables, PC, flags (PSW), registers, context) before entering into ISR?

How can we resume back original context without any data lose with multiple thread environment.

Answer 1

I tried to google it & I found the needed information from this:

1. Interrupts
2. Context Switch

Thanks @Drew McGowen

So to sum up, the general sequence for an interrupt is as follows:

Foreground code is running, interrupts are enabled
Interrupt event sends an interrupt request to the CPU
After completing the current instruction(s), the CPU begins the interrupt response
automatically saves current program counter
automatically saves some status (depending on CPU)
jump to correct interrupt service routine for this request
ISR code saves any registers and flags it will modify
ISR services the interrupt and re-arms it if necessary
ISR code restores any saved registers and flags
ISR executes a return-from-interrupt instruction or sequence
return-from-interrupt instruction restores automatically-saved status
return-from-interrupt instruction recovers saved program counter
Foreground code continues to run from the point it responded to the interrupt

As usual, the details of this process will depend on the CPU design. Many devices use the hardware stack for all saved data, but RISC designs typically save the PC in a register (the link register). Many designs also have separate duplicate registers that can be used for interrupt processing, thus reducing the amount of state data that must be saved and restored.

Note that saving and restoring the foreground code state is generally a two-step process for reasons of efficiency. The hardware response to the interrupt automatically saves the most essential state, but the first lines of ISR code are usually dedicated to saving additional state (usually in the form of saving condition flags if not saved by the hardware, along with saving additional registers). This two-step process is used because every ISR will have different requirements for the number of registers it needs, and thus every ISR may need to save save different registers, and different numbers of registers, assuring all appropriate state data is saved without wasting time saving registers unnecessarily (that is, saving registers that are not modified in the ISR and thus didn’t need to be saved). A very simple ISR may not need to use any registers, another ISR may need to use only one or two registers, while a more complicated ISR may need to use a large number of registers. In every case, the ISR should only save and restore those registers it actually uses.

Answer 2

I'm sure there are different implementations based on the CPU you're using. On a general level, the function calls store the input parameters within the given registers (%o0-%o9) on SPARC and are available in the (%i0-%i9) registers in the calle's function. The callee function will then place the return value in the %i0 register to be available in the %o0 register for the caller function. According to the Sparc Manual, each interrupt is:

Accompanied by data, referred to as an “interrupt packet”. 
An interrupt packet is 64 bytes long, consisting of eight 64-bit doublewords.

According to this source, the data in your current executing thread is:

   Saved either on a stack (PDP-11, VAX, MIPS, x86_64) 
   or in a single set of dedicated registers (ARM, PowerPC)

The above source mentions how interrupts are handeled on a couple of different architectures as well.

Please let me know if you have any questions!