Why ISR contains no arguments and return type is void

Because "we" don't call the ISR --- the CPU does that by itself, and it has no arguments in hand to pass in, nor would it know what to with a result value, if there were one.

I'm curious. What arguments would you want to pass to an ISR? And where would the returned thing go?

Keep in mind that generally (except on some CPUs, where 'software triggered' interrupts are used for OS calls) you have no control exactly when an interrupt would occur. It doesn't make sense to pass it things, or have things returned.

Al

The ISR gets called by the CPU in the middle of the running code. The CPU pushes all of the current program's execution information (eg. program counter, stack pointer and others) and then runs the ISR. So there really is no calling code for the ISR...thus nobody to pass arguments or fetch results.

Technically I suppose a CPU could pass an argument to an ISR, but I don't know if it would be meaningful at all.

Why did you want to? Or are you just curious?

If you want to return information from an ISR to your main program, you can set global flags in the ISR. Just make sure nobody else is modifying the global flags when the ISR gets called. You might get an inconsistent state.

This is not true of all processors. With some, the parameter passed (by the CPU) is the Interrupt number which you can then use inside the ISR.

tim

I'm not the OP, but the interrupt number/index/vector/whatever might be handy. That way you could hook the same ISR to multiple interrupts and have it behave slightly differently based on which interrupt caused it.

For example, you've got 4 UARTs and the receive processing for all of the is identical (except for which UART you access and which buffer you put data into). Hooking one ISR to all four and then using the "parameter" to determine which UART/buffer-pair to service would be elegent.

I honestly don't see the big gain between that and 4 micro-ISRs that each do essentially just

ACC := {this interrupt's number} jump to commonISR

The ISR can't return a value because technically there is no "caller" to the ISR, so it's declared as type void.

For this same reason no arguments can be passed to the ISR since there is no caller, no telling where program flow is at the time of the interrupt, etc,,.

-Bruce

Not a big gain, but sometimes a few instructions matter.

If they do, then nice style will have to yield to efficiency. On a CPU with individual ISR vectors, you just have to not use the trick I just showed. On a single-ISR platform, you'ld have to start worrying about how to squeeze single instructions out of a multi-way branch statement.

You've got a lot of answers already, so you might have grasped the concept. In some cases though, when the interrupt handler is called by the OS, the former can have arguments and return value. In QNX6 we (tinw) use the interrupt handlers that have the following prototype

const struct sigevent* handler (void* area, int id);

The handler is called by the OS kernel and returns to the OS kernel. It does not (and should not) deal with interrupt controller directly, has it's own rather limited stack and can be preempted by a handler of higher priority interrupt.

BTW, in QNX4 the prototype was

pid_t handler (void);

HTH, Vadim

what about polling the "interrupt" flag (of all the devices connected to that interrupt line) which is set when an interrupt gets serviced?