Re: Compiler support for a faster interrupt response

Henry Dan Lambright <hdlambri@cs.arizona.edu>
Thu, 26 Oct 1995 04:15:02 GMT

          From comp.compilers

Related articles
Re: Compiler support for a faster interrupt response ah739@cleveland.Freenet.Edu (1995-09-29)
Re: Compiler support for a faster interrupt response whalley@sed.cs.fsu.edu (David Whalley) (1995-09-29)
Re: Compiler support for a faster interrupt response mav@sleepy.local.org (1995-09-29)
Re: Compiler support for a faster interrupt response sethml@sloth.ugcs.caltech.edu (1995-10-03)
Re: Compiler support for a faster interrupt response gary@Intrepid.COM (1995-10-06)
Re: Compiler support for a faster interrupt response hdlambri@cs.arizona.edu (Henry Dan Lambright) (1995-10-26)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Henry Dan Lambright <hdlambri@cs.arizona.edu>
Keywords: optimize, architecture
Organization: Compilers Central
References: 95-10-030
Date: Thu, 26 Oct 1995 04:15:02 GMT

> 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
--


Post a followup to this message

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