Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!ames!elroy!ucla-cs!frazier From: frazier@oahu.cs.ucla.edu (Greg Frazier) Newsgroups: comp.arch Subject: Re: Register usage Message-ID: <24394@shemp.CS.UCLA.EDU> Date: 31 May 89 18:31:25 GMT References: <259@mindlink.uucp> <25382@ames.arc.nasa.gov> <1RcY6x#64Zq3Y=news@anise.acc.com> <3427@bd.sei.cmu.edu> Sender: news@CS.UCLA.EDU Reply-To: frazier@cs.ucla.edu (Greg Frazier) Organization: UCLA Computer Science Department Lines: 62 In article <3427@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >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. Actually, this is not entirely true. While you do have to save all currently used registers, it is actually optimal to only restore a single window within the register file (if you are using windows - if you're not, then yes, all currently used must be restored). In addition, if you have a cache, saving the registers is very fast (unless your cache is write-through). If the cache is context dependent, then the time required to flush the cache and the delay caused by a cold start will make the register save/restore time insignificant. > >For this reason, I think people with hard real-time applications should >look pretty carefully at context switch costs. Hard real-time applications always have problems with memory hierarchies - cache misses can be just as painful as register saving/restoring, and don't even mention page faults! :-) >> 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. Obviously, for realtime applications, you need to save a window (or some set of registers) for interrupt handling. And, equally obvious, you still run into problems if you get a high-priority interrupt while you are handling a high-priority interrupt. Hard realtime systems require a high degree of predictability (i.e. you have to thoroughly understand your application). As I mentioned before, introducing hierarchical memory makes the task of understanding MUCH more difficult. Add to this multiple processors (just to add another issue), and you have no choice but to do soft realtime, unless your application is VERY simple. ...And, if your application is that simple, you can (?) take register behavior into account (I think - I have not done any research in hard realtime, so I'm just blathering). Greg Frazier &&&&&&&&&&&&&&&&&&!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(((((((((((((((((( Greg Frazier o Internet: frazier@CS.UCLA.EDU CS dept., UCLA /\ UUCP: ...!{ucbvax,rutgers}!ucla-cs!frazier ----^/---- /