🚀 go-pugleaf

> 
> Actually, if you have a fast, pipelined memory interface, it is not so
> expensive after all to save the complete context automatically.  CDC
> and Cray have been doing various forms of this for many years.  
> CDC 6000/7000 and Cyber 70 and 170 machines this is known as "exchange
> jump".  The Cyber 205 actually swaps 256 registers in less than 200 
> CPU cycles (not to be confused with the longer memory cycles).  It can
> do this because of the way the memory interface is structured.  It may
> look "expensive", but simplifies register management so much that it
> is actually cheap. It works well and probably provides a net 
> performance/price improvement on machines which are going to have a 
> fast, pipelined memory interface anyway

 	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.