Differences between interrupt service routine (ISR) and a subroutine

"Dave" <dave@comteck.com> wrote in message 
news:pan.2006.11.29.00.41.29.735054@comteck.com...
> On Tue, 28 Nov 2006 22:38:30 +0000, Wilco Dijkstra wrote:
>
>>
>>> On 2006-11-28, Wilco Dijkstra <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>>>
>>>> The hardware could set up a few registers and the compiler
>>>> would assign parameters to those registers on functions marked
>>>> as interrupts - very easy to implement. You could ignore them if
>>>> you didn't support them.
>>
>> The return address is can already be made available via an
>> intrinsic and many compilers support this. I was thinking more
>> along the lines of allowing the user not only to choose which
>> interrupt routine is called for a certain interrupt but also some
>> parameters to pass to the routine when that interrupt triggers.
>> It is in effect an alternative to ARM's FIQ scheme but rather than
>> spending lots of transistors on 7 extra registers that are hardly
>> used, they could be loaded for free while the CPU branches to
>> the handler.
>
> And what do you do when you have 1024 ISRs, each wanting a parameter or
> two or three or ... ?

What problem are you thinking of? This would be stored in a table
of course, and if you have so many ISRs then main memory would
be best (but limiting the number would be feasible too, not all ISRs
would benefit equally). The point is that it takes less space and time
to do this in hardware than to load those arguments the usual way in
software, so adding extra hardware is beneficial.

The same is true for directly branching to the right ISR (vectored
interrupts) rather than using a switch statement polling interrupt
registers to find out where to branch.

Wilco 

Tom Lucas wrote:
> "2005" <uws2003@yahoo.com> wrote in message 
> news:1164736936.337323.40270@j44g2000cwa.googlegroups.com...
>> Hi
> 
> This is another homework question isn't it?
> 
>> What are the differences between ISR and a subroutine in embedded
>> systems, how about the following:
>> - interrupts are disabled by the microprocessor prior to calling the
>> isr
> 
> Not always - google for nested interrupts.
> 
>> - isr's are always smaller
> 
> Not necessarily. ISRs _should_ be kept small but that doesn't always 
> happen.
> 
>> - an isr cannot be written in C
> 
> Not true but when written in C you normally need an attribute to tell 
> the compiler that the function is to be an ISR.
> 
>> - a subroutine always has arguments
> 
> Not true. void Subroutine(void); is a perfectly acceptable prototype.
> 
>> - the CPU flags are stored on the stack in addition to the return
>> address
> 
> That is true (although I suspect some pedants will find an example of 
> systems that don't).
> 
> 
> 
The PIC the 8052

2005 wrote:
> Thanks and wondering if
> - difference between an isr and a subroutine is that an isr has no
> arguments
> is true or not?
> 


  The answer is none.  It is in the use.

On some systems a subroutine can be also used as an ISR.
The details are MPU specific.

A subroutine is called by the program.  It is synchronous to execution.
An ISR can be called at any time is executions is asynchronous.

>-----< someone who calls himself "2005" >
> What are the differences between ISR and a subroutine in embedded
> systems

It's the same in embedded systems as in every other system: an ISR is
called by the processor after it has received a hardware signal,
whereas a subroutine is called by software.

--=20
Fredrik =D6stman

On Tue, 28 Nov 2006 19:37:46 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

>
>Well I can see some good uses for interrupts with arguments,
>making interrupt routines even easier to write in C. I'm sure
>someone has patented the idea already as it is quite obvious...

The only use I could think of is that you have multiple interrupt
sources on the same interrupt vector, thus the hardware delivered
argument would identify which interrupt source activated the ISR. The
argument could be the card slot, the I/O or (low bits of the) memory
address of the controller etc.

You would not have to scan all the interrupt status registers of each
interrupt source on the same interrupt level to find the (first)
interrupting source.

Of course, this system would be redundant, if sufficient interrupt
vectors would be available for each interrupt source, but since many
processors have only 8 or 16 interrupt vectors, the same interrupt
vector must be shared between multiple interrupt sources in complex
systems.

Paul

Grant Edwards wrote:
> On 2006-11-28, Wilco Dijkstra <Wilco_dot_Dijkstra@ntlworld.com> wrote:
> 
>>> Since you don't know what is in the resisters when the ISR is
>>> jumped to the idea of function arguments is meaningless.
> 
> The unstated assumption seems to be that function arguments are
> passed in registers?
> 
>> Well I can see some good uses for interrupts with arguments,
>> making interrupt routines even easier to write in C. I'm sure
>> someone has patented the idea already as it is quite obvious...
> 
> Obvious but impossible (in general). The hardware designer has
> no way of knowing how the ISR is going to expect arguments to
> be passed. If varies from one language to the next, from one
> compiler to the next, and even from one build to the next when
> compiler flags are changed.
> 

I can think of a number of uses for ISR arguments for larger 
architectures, such as the m68k.  Obviously you'd need compiler support 
and/or horrible macros with inline assembly to put it all together, but 
it might be useful:

You could have the interrupt/exception vector as an argument, letting 
you more easily write generic handlers (the m68k puts this vector number 
on the stack).

You could include a pointer to the address following the pre-exception 
PC - useful for software interrupts followed by data, which are 
sometimes used for operating system calls.

You could include a pointer to the status register on the return stack, 
useful for modifying the interrupt enable status when the ISR returns.

"Neil" <NeilKurzm@worldnet.att.net> wrote in message 
news:JY9bh.384791$QZ1.43268@bgtnsc04-news.ops.worldnet.att.net...
> Tom Lucas wrote:
>> "2005" <uws2003@yahoo.com> wrote in message 
>> news:1164736936.337323.40270@j44g2000cwa.googlegroups.com...
>>> Hi
>>
>> This is another homework question isn't it?
>>
>>> What are the differences between ISR and a subroutine in embedded
>>> systems, how about the following:
>>> - interrupts are disabled by the microprocessor prior to calling the
>>> isr
>>
>> Not always - google for nested interrupts.
>>
>>> - isr's are always smaller
>>
>> Not necessarily. ISRs _should_ be kept small but that doesn't always 
>> happen.
>>
>>> - an isr cannot be written in C
>>
>> Not true but when written in C you normally need an attribute to tell 
>> the compiler that the function is to be an ISR.
>>
>>> - a subroutine always has arguments
>>
>> Not true. void Subroutine(void); is a perfectly acceptable prototype.
>>
>>> - the CPU flags are stored on the stack in addition to the return
>>> address
>>
>> That is true (although I suspect some pedants will find an example of 
>> systems that don't).
>>
>>
>>
> The PIC the 8052

There's always bloody one isn't there ;-) Are you sure about the PIC? 

"2005" <uws2003@yahoo.com> wrote in message 
news:1164739817.612931.190780@l39g2000cwd.googlegroups.com...
>
> Thanks and wondering if
> - difference between an isr and a subroutine is that an isr has no
> arguments
> is true or not?

I did say that in my first response but I'll expand a bit...

Whilst normally ISRs have no arguments then you can see from the rest of 
thread that that is not stricly true. If you can sum up what has been 
said in here (and understand it) then your tutor should definitely be 
awarding extra credits.

However take the following C subroutine:
void InitialiseLCD(void) {
   SetUpTheRegisters();
   ClearTheFrameBuffer();
   TurnOnTheBackLight();
}

No arguments required and a perfectly acceptable function.
 

Tom Lucas wrote:
> "Neil" <NeilKurzm@worldnet.att.net> wrote in message
> news:JY9bh.384791$QZ1.43268@bgtnsc04-news.ops.worldnet.att.net...
> > Tom Lucas wrote:
> >> "2005" <uws2003@yahoo.com> wrote in message
> >> news:1164736936.337323.40270@j44g2000cwa.googlegroups.com...
> >>> Hi
> >>
> >> This is another homework question isn't it?
> >>
> >>> What are the differences between ISR and a subroutine in embedded
> >>> systems, how about the following:
> >>> - interrupts are disabled by the microprocessor prior to calling the
> >>> isr
> >>
> >> Not always - google for nested interrupts.
> >>
> >>> - isr's are always smaller
> >>
> >> Not necessarily. ISRs _should_ be kept small but that doesn't always
> >> happen.
> >>
> >>> - an isr cannot be written in C
> >>
> >> Not true but when written in C you normally need an attribute to tell
> >> the compiler that the function is to be an ISR.
> >>
> >>> - a subroutine always has arguments
> >>
> >> Not true. void Subroutine(void); is a perfectly acceptable prototype.
> >>
> >>> - the CPU flags are stored on the stack in addition to the return
> >>> address
> >>
> >> That is true (although I suspect some pedants will find an example of
> >> systems that don't).
> >>
> >>
> >>
> > The PIC the 8052
>
> There's always bloody one isn't there ;-) Are you sure about the PIC?

I know another, the 8008.  Or I may be confused, maybe it didn't have
interrupts!  It only had an 8 level hardware stack for subroutines, so
it was pretty useless for a lot of things and was very quickly replaced
by the 8080.

In general, an interrupt without a save of the PSW is pretty useless.
I guess you could manually save it as the first thing in the ISR, but
that requires that the IRQ not change any status bits before the PSW
gets saved.  Otherwise anytime you want to use a status flag, you have
to disable interrupts between the setting and the checking.

rickman wrote:
> 
... snip ...
> 
> I know another, the 8008.  Or I may be confused, maybe it didn't have
> interrupts!  It only had an 8 level hardware stack for subroutines, so
> it was pretty useless for a lot of things and was very quickly replaced
> by the 8080.
> 
> In general, an interrupt without a save of the PSW is pretty useless.
> I guess you could manually save it as the first thing in the ISR, but
> that requires that the IRQ not change any status bits before the PSW
> gets saved.  Otherwise anytime you want to use a status flag, you have
> to disable interrupts between the setting and the checking.

Not in the 8008.  There was no way to save the CPU state.  The only
way to use the interrupt system was to reserve a register for
interrupt entry use alone.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>