Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!pt.cs.cmu.edu!sei!firth From: firth@sei.cmu.edu (Robert Firth) Newsgroups: comp.arch Subject: Re: Register usage Message-ID: <3427@bd.sei.cmu.edu> Date: 31 May 89 12:31:03 GMT References: <259@mindlink.uucp> <25382@ames.arc.nasa.gov> <1RcY6x#64Zq3Y=news@anise.acc.com> Reply-To: firth@sei.cmu.edu (Robert Firth) Organization: Software Engineering Institute, Pittsburgh, PA Lines: 29 In article <1RcY6x#64Zq3Y=news@anise.acc.com> lars@salt.acc.com (Lars J Poulsen) writes: >From a humble applications programmer, who occasionally has written a bit >of kernel code: The biggest pain with an architecture that exposes too >large a register file is saving and restoring on context switches. It's more than a pain; it can cause a severe performance penalty in some application domains. This is one of the reasons I don't like register-file machines: ALL the registers have to be saved and restored across a full context switch, and there are an awful lot of them. Moreover, a hardware instruction isn't much help, since the holdup is the actual data copy to and from memory, not the instruction fetch. For this reason, I think people with hard real-time applications should look pretty carefully at context switch costs. > While >interrupt service routines can ignore this and store only what they >need, context switches require storing of the entire register set. There's another pitfall here. Some machines use the same register window mechanism to handle interrupts, automatically shifting to a new set. If the interrupt hits you at just the wrong call depth, you get an automatic register spill. So about one-sixth or one-fourth of the time, it takes maybe three times as long overall to field the interrupt and maybe thirty times as long to reach the first instruction of the handler. Since hard real time people care about predictability next only to performance, this gives loads of grief.