;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; 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