EmbeddedRelated.com
Forums

Differences between interrupt service routine (ISR) and a subroutine

Started by 2005 November 28, 2006

Wilco Dijkstra wrote:

> Well I can see some good uses for interrupts with arguments, > making interrupt routines even easier to write in C.
In ADI VDSP, the interrupt handlers do have arguments.
> I'm sure > someone has patented the idea already as it is quite obvious...
An interrupt handler is somewhat similar to a thread. If threads can have arguments, the interrupt handlers can have it too. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Vladimir Vassilevsky wrote:
> > > Wilco Dijkstra wrote: > >> Well I can see some good uses for interrupts with arguments, >> making interrupt routines even easier to write in C. > > > In ADI VDSP, the interrupt handlers do have arguments. > > >> I'm sure >> someone has patented the idea already as it is quite obvious... > > > An interrupt handler is somewhat similar to a thread. If threads can > have arguments, the interrupt handlers can have it too.
and then there are Software Interrupts - it's common for those to have arguments. ( See BIOS calls etc ). -jg
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.
All of the processors I've used already do that (store return address and status information in a known location), so I guess all that's missing is a few lines of code in the compilers. -- Grant Edwards grante Yow! A can of ASPARAGUS, at 73 pigeons, some LIVE ammo, visi.com and a FROZEN DAQUIRI!!
"Grant Edwards" <grante@visi.com> wrote in message 
news:12mp47ilq7kab2d@corp.supernews.com...
> 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?
Absolutely, if you have a decent set of registers it is the most efficient way of passing arguments.
>> 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.
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. Wilco
"Grant Edwards" <grante@visi.com> wrote in message 
news:12mpcnu2arb6854@corp.supernews.com...
> 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. > > All of the processors I've used already do that (store return > address and status information in a known location), so I guess > all that's missing is a few lines of code in the compilers.
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. Wilco
In article <MPG.1fd6562aaec84d6d989d8e@newsgroups.bellsouth.net>, 
jim@reallykillersystems.com says...
> In article <1164739817.612931.190780@l39g2000cwd.googlegroups.com>, > uws2003@yahoo.com says... > > > > Thanks and wondering if > > - difference between an isr and a subroutine is that an isr has no > > arguments > > is true or not? > > > Since you don't know what is in the resisters
(DUH, registers, NOT resistors)
> when the ISR is jumped to > the idea of function arguments is meaningless. > >
In article <12mp47ilq7kab2d@corp.supernews.com>, grante@visi.com says...
> 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?
No, but you need to know where your "arguments" are and if they aren't somehow passed by a register or a pointer in a register then you are just talking about a global variable and that is not a function argument in my book.
> > > 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. > >
In article <456cacd6$1@clear.net.nz>, no.spam@designtools.maps.co.nz 
says...
> Vladimir Vassilevsky wrote: > > > > > > Wilco Dijkstra wrote: > > > >> Well I can see some good uses for interrupts with arguments, > >> making interrupt routines even easier to write in C. > > > > > > In ADI VDSP, the interrupt handlers do have arguments. > > > > > >> I'm sure > >> someone has patented the idea already as it is quite obvious... > > > > > > An interrupt handler is somewhat similar to a thread. If threads can > > have arguments, the interrupt handlers can have it too. > > and then there are Software Interrupts - it's common for those to have > arguments. ( See BIOS calls etc ). > > -jg > >
Not really an interrupt in the hardware sense since the main line code knows when they are called and actually sets up registers to pass info. BIOS calls are really just common subroutines that are in firmware.
James Beck wrote:
> > Not really an interrupt in the hardware sense since the main line code > knows when they are called and actually sets up registers to pass info. > BIOS calls are really just common subroutines that are in firmware.
Correct, but the op (or his tutor) did not say hardware interrupt. Also, subroutines have an address that is resolved at compile/link time, but with a SW interrupt BIOS call, the users code has no knowledge of the address it is (finally) calling. There are also system exception interrupts, that are slightly different again.. It's up to the OP, to present all this in a choerent assigment.... -jg
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 ... ? ~Dave~