Re: Compiler support for a faster interrupt response

sethml@sloth.ugcs.caltech.edu (Seth M. LaForge)
Tue, 3 Oct 1995 17:56:03 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: sethml@sloth.ugcs.caltech.edu (Seth M. LaForge)
Keywords: architecture, realtime
Organization: California Institute of Technology, Pasadena, CA
References: 95-09-154
Date: Tue, 3 Oct 1995 17:56:03 GMT

yoon ji hoon_4S <yjh@news.kreonet.re.kr> wrote:
>Whenever interrupt occurs, it is basically true that
>all global registers should be saved in the interrupt
>prolog and restored in the epilog.


Why? On all processors that I've worked with, there is no reason to
save and restore any registers which you don't modify in your
interrupt routine. On the 68K and 6.8K processors you don't even have
to explicitly save and restore registers in interrupt handlers, since
they're saved automatically in the interrupt frame.


>But in the case of 29K processor, nearly 40 ~ 50 registers
>should be saved and restored at each interrupt, which, of course,
>increses the interrupt response time.
>
>Thus I want to survey various existing techniques for conquering this
>heavy register saving/restoring problem.
>Would you help me?


As I mentioned above, don't use many registers and you don't have to
pay for many registers.


Seth


--


Post a followup to this message

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