Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!pioneer!lamaster From: lamaster@pioneer.UUCP Newsgroups: comp.arch Subject: Re: register saving on context switch Message-ID: <507@ames.UUCP> Date: Tue, 3-Mar-87 16:45:56 EST Article-I.D.: ames.507 Posted: Tue Mar 3 16:45:56 1987 Date-Received: Fri, 6-Mar-87 00:35:26 EST References: <4376@columbia.UUCP> <448@cpocd2.UUCP> <5763@amdahl.UUCP> <420@ames.UUCP> <542@houxv.UUCP> Sender: usenet@ames.UUCP Reply-To: lamaster@pioneer.UUCP (Hugh LaMaster) Distribution: na Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 116 Keywords: exchange, register In article <542@houxv.UUCP> rdt@houxv.UUCP (R.TRAUBEN) writes: > > Could anyone share with us how the CPU hardware and operating > system coordinate their response to a faulted copyback midway > thru an exchange jump? > > Let 16 registers be copied back to memory (actually stack in > main memory) and a fault occurs at register copyback in word > 5 of the 16 total. Consider 2 cases of fault: fault due to a > page not present (stack overflow) and fault due to a memory > parity error. > > I assume the os must immediately respond to the fault by moving > the registers out to a temporary safe area of memory before > switching to the new process. (Recall that part of the old > process context still resides in the shared registers) > > How does the hardware differentiate this kind of fault from > non-context switch memory faults when calling the OS fault > handler? How does the hardware get the base address of > the temporary safe area? What happens if the copy to the > safe area faults as well? > > If the context being saved is the contents of a copyback > stack cache rather than a those of a register file, the > situation gets more interesting since one can not typically > fault the instruction which wrote the word into the cache > until cache copyback discovers the problem with main memory. > > Any comments? > >Richard Trauben >ATT Information Systems >WE32x00 Processor Development >Holmdel, NJ. > > > The best answer to this question is to refer you to the Cyber 205 Hardware Reference Manual, CDC #60256020. However, there are some things that could be said briefly: You are certainly correct that the hardware must know what physical memory to swap the registers to if a page fault occurs. I glossed over the fact that the Cyber 205 and lower Cyber's have a somewhat different structure. Because memory is always resident on a lower Cyber (no page faults), any memory address can be used to swap. The Lower Cyber exchange jump need not be to the operating system kernel, although there is a tree-like structure. On the Cyber 205, the exchange jump is referred to as "exit force" and it is always between the operating system kernel and another process. On the lower Cybers, a "job supervisor" could exchange to/from a job without going through the kernel. On the Cyber 205, to get to the equivalent of a job supervisor, first the process exits to the kernel, and the kernel then exits to supervisor. On both types of machines, there are a number of hidden registers in addition to the visible registers. These registers, when written out to memory, are referred to as the "exchange package". One of these registers holds the physical memory address of the exchange package that is to be read in if an exchange is done. So, to make a long story short, in both cases the registers are exchanged with a physical memory location. Therefore, there is no possibility of a page fault. [If a fatal SECDED fault occurred (one of the other questions) then the CPU would stop on a fatal error (whether an exchange was taking place or not). These only happen about once a year and are not a problem.] In the case of the Cyber 205, it is the kernel's job to manage the exchange packages for all the processes in the system. Since it doesn't take very long to exchange to/from the kernel, the overhead is small. On the Cyber 205, there is an additional user state instruction which exchanges registers (though not the hidden registers) which runs just as fast. If it encounters a page fault, the instruction is continued (not restarted) when the task is restarted. The Cyber 205 has instruction continuation for many other instructions as well, since it has memory to memory vector instructions which may cause page faults. Although much of the machine is "hardwired", instruction continuation is "all handled in the microcode". There is no data cache. There is an instruction cache. The 256 registers were a conscious design decision. In practice, the 256 registers are just about the right size to make sure that for almost all Fortran modules, local scalar variables are already in registers. And since the vector instructions are memory to memory, and run through very large amounts of memory very fast, it would be counterproductive to read vector data into a cache. (With a somewhat different organization, the Alliant mini-super does this, I seem to recall). I did not mean to mislead anyone into thinking that the Cyber 205 has an message passing structure. It simply has a very fast way to load and unload its large register file, and uses it to produce a very fast context switch between a process and the kernel. The kernel does all the message passing (actually, that is almost all it does. It also schedules.) With a high performance memory interface, it is not catastrophically expensive to save registers. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "In order to promise genuine progress, the acronym RISC should stand for REGULAR (not reduced) instruction set computer." - Wirth ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")