;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; OPERATIONS ON CONTROL PDLs

;;; SWAP IN AND WIRE		-not needed-
;;; The control PDL (or at least the part being dumped to) must be wired
;;; since the call hardware dumper isn't allowed to take page faults (or
;;; any call hardware operation).

;;; UNWIRE			-not needed-
;;; only the current control pdl need be wired.

;;; ASSURE SPACE TO DUMP IN
;;; For the current stack group, there must be enough remaining space in the
;;; control pdl (which must be wired) to hold what could potentially be the
;;; entire state of the call hardware.

;;; GROW
;;; control flow for the program might have a deep enough call stack
;;; that the previously allocated control pdl might not be big enough.
;;; this operation is similar to that of growing arrays.
;;; Wiring and unwiring must occur when a bigger control pdl is created.

;;; CONTEXT SWITCH
;;; when a context switch between stack groups occurs the entire call hardware
;;; state must be dumped into the control pdl associated with the outgoing
;;; stack group and restored from the control pdl state of the incomming stack group.
;;; These operations are similar to overflow and underflow handling.
;;; Wiring and unwiring occur at this point.

;;; HANDLE OVERFLOW
;;; when the program overflows the call hardware then its state must be dumped
;;; to the control pdl and restored later.  This dumping must occur on call boundaries.

;;; HANDLE UNDERFLOW
;;; when the program does more returns than the call hardware remembers and there
;;; was previously an overflow, then the state that was dumped to service the overflow
;;; must now be restored.  If there was no previously dumped state then the machine
;;; will have returned to the event horizon.

;;; SCAVENGE
;;; The control pdl must be scavenged in a manner similar to the way the registers
;;; are scavenged.  The scavenger must touch those pieces of the dumped call hardware state
;;; which are boxed, and only those which are boxed.

;;; TOOLS FOR THE DEBUGGER TO LOOK AT THEM
;;; It is probably the case that the debugger will run in a different stack group than
;;; the program being debugged.  In this case, the entire state of the call hardware
;;; for the debugged stack group will be represented in a control pdl.


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; at the base of the call hardware stack a CALL has just occurred.
;;; That call will have come from the call stack underflow handler.

;;; The call stack underflow handler (catcher) uses register set #xff for O and A.
;;; At the base of the call stack will be an entry which will return #xff to O and A,
;;; and the RPC will be a routine which preserves the return values, scrolls the call
;;; stack, and returns with the preserved return values.
;;; This is why the call hardware may only be scrolled so that the base is at a call boundary.

;;; These global registers are used by the control pdl code:
;;;  GR:*CONTROL-PDL*		contains the currently active control pdl.
;;;  GR:*CONTROL-PDL-POINTER*	virtual address into the current control pdl where the next
;;;				record will be written as an unboxed locative.
;;;  GR:*CONTROL-PDL-LIMIT*	if GR:*CONTROL-PDL-POINTER* reaches this then the control pdl is full. 
;;;  GR:*CH-BASE-CSP*		the value of the call stack pointer above which the call stack is valid.
;;;  GR:*CH-TEMP-0*		temporaries used by the call hardware dumper and restorer while
;;;  GR:*CH-TEMP-1*		they can't use locals
;;;  GR:*CH-TEMP-2*
;;;  GR:*CH-TEMP-3*
;;;  GR:*CH-TEMP-4*
;;;  GR:*CH-TEMP-5*
;;;  GR:*CH-TEMP-6*
;;;  GR:*CH-CONTROL-PDL-INDEX*	used by the restorer.  (could just be another temporary)
;;;  GR:*NEXT-CONTROL-PDL*	control pdl to context-switch to