Difference between ISR and Function Call?

Question

I want to understand difference between ISR (Interrupt Service Routine) and Function call.

I feel both the function call and ISR are the same from the hardware perspective. Please Correct me if I am wrong. All I could found about ISR and Function call is as follows:

ISR:

• Asynchronous event that can occur any time during the execution of the program

• Saves the PC, Flags and registers on the stack and disables all the interrupts and loads the address of the ISR

• ISR cannot have arguments that can be passed to it

• Cannot return values
• Enables the interrupts
• Generally small as they are taking the time of some other process
• Some of ISR have have their own stack

Function:

• Occurs when ever there is a function call

• Saves the PC and registers on the stack

• Can have arguments

• Can return values

• No restriction on the size and duration of execution

Is there any more difference other than this ? Please let me know. I have also read about having a function call from ISR how does that take place. Please highlight on it.

Answer 1

So having asserted that they are the same, you go on to list the ways in which they are different - which perhaps rather answers your question.

Your first four points about ISRs are broadly and generally true. The points about enabling interrupts is not necessarily the case and is an implementation decision by the programmer, and may be determined by the architecture, and being small is a guideline not a requirement - and "small" is entirely subjective".

The differences are not so much in respect of how they are coded (though ISR's typically impose a number of restrictions and may also have privileges that normal functions do not), but rather in how they are invoked and the behaviour of the processor.

A function (or procedure or sub-routine more generally) must be explicitly called and is part of the same context and thread of execution as its caller. A hardware ISR is not explicitly called but rather invoked by some external event (external to the processor core that is - on-chip peripherals may generate interrupts). When an interrupt is called the context of the current thread is automatically preserved before switching context to the ISR. On return, the reverse context switch occurs restoring the state of the processor before the interrupt so that execution continues from the point of interruption.

The mechanism can be complicated by the presence of a multi-threaded operating system or scheduler whereby the ISR itself may cause a thread-context switch so that on return from an ISR a different thread of execution or context is switched in. Such mechanisms are managed by the operating system in this case.

There is another kind of ISR supported on some processors - that of a software interrupt. A software interrupt is used like a function call in the sense that it is explicitly invoked by an instruction rather than a single event, but offers an indirection mechanism whereby the caller does not need to know the address of the ISR and indeed that address may change. In that sense it is little different than calling a function through a pointer, but because it is an ISR it runs in the interrupt context, not the caller's context, so may have restrictions and privileges that a normal function does not.

Fundamentally an interrupt is able to respond directly and deterministically to events where otherwise you might poll or test for an event then handle it, but could only handle it at the time you choose to test for it rather than on its actual occurrence, which may be variable and unacceptably long.

Answer 2

The main difference is that interrupt handlers are, (usually), invoked by peripheral hardware - an actual hardware signal is generated by the peripheral and hardware in the processor transfers control to the appropriate handler without any action by the code that was running before the interrupt. Unlike functions, there is no call - execution is ripped away from the interrupted code by the processor hardware.

On OS that support multithreading/processes, function calls take place witin the same process/thread context as the caller. An interrupt, OTOH, has no thread or process context - a network interrupt resulting from a background BitTorrent download may occur while you are editing a Word document, and so the handler is very restricted in what it can do. It can load data to/from pre-allocated buffers belonging to the process/thread that it is bound to, it can signal a semaphore, it may be able to set OS event flags. That's about it.

Often, an interrupt-handler performs an interrupt-return directly, so allowing execution of the interrupted code to proceed wtihout any further interference. On simpler controllers, like yopur 8051, that often run embedded code without a compex OS, this is the only course available. With a preemptive multithreaded OS, an interrupt-handler has the additional option of performing its interrupt-return via OS code and so causing a scheduler run. This allows interrupt-handlers to make threads that were waiting for the interrupt ready, and possibly running, (and so maybe preempting the thread that was originally interrupted). This allows such systems to have good I/O performance without any polling.

The hardware interrupt sources my be peripherals embedded in the processor chip - network controllers, disk controllers, display controllers, DMA controllers, USB controllers, intercore-comms controllers, (on processors with multiple cores), timers etc. or interrupt-request pin/s on the package can be used to generate an interrupt from an external hardware source, (maybe a pushbutton, keyboard, keypad or touchscreen hardware).