Re: Compiler support for a faster interrupt response

> On Fri, 29 Sep 1995, Maurizio Vitale wrote:
>
> > yoon ji hoon_4S <yjh@news.kreonet.re.kr> writes:
> >
> > > Whenever interrupt occurs, it is basically true that
> > > all global registers should be saved in the interrupt
> > > prolog and restored in the epilog.
> >
> > Sounds basically false to me:
> >
> > first of all only registers which are actually _used_ in the
> > interrupt handler must be saved. Second thing interrupt
> > handlers often check a few things (like a character being
> > available somewhere or other change of state in devices) and
> > this can be often done with very few registers, so you might
> > be able to push the saving/restoring of registers down paths
> > that are rarely executed.


Yes. Depending on your processor, you probably can speed things up. I
found those kind of techniques with interrupt handlers to be very useful.


Divide up the functions the handler is going to do. Put the simplest
ones, such as ticking the clock, checking io, etc, near the top of the
routine. Handle those operations using a minimal set of registers. If
you're clever you may only need 2 or 3 "kernel" registers for that.


If possible on your hardware, save the t registers only if you break out
of the assembly code to call other functions (such as io interrupt handler
functions.)


(Again if your setup allows,) save the s registers *only* if you do a
context switch. This possibly will be rare in comparison to the total
number of interrupts you receive. Maybe you get 1000 ethernet packets for
every context switch.


These changes may make your int handler much more complex- especially if
"interrupts within interrupts" are allowed. But it also may be worth it to
you in speed.


Dan
UA, Tucson
--

Return to the comp.compilers page.
Search the comp.compilers archives again.