perm filename SWAP.DOC[NEW,LSP] blob sn#548017
filedate 1980-11-26 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00002 00002 ∂25-Nov-80 2237 RPG Swapping
∂25-Nov-80 2237 RPG Swapping
To: BIS, RPG
The problems of swapping are:
1. Deciding on the size of the swapping area.
2. Deciding what goes in there to avoid thrashing
or swapping things you always use.
3. There has to be a surrounding environment to
call the individual routines. If you say (baz 7),
and baz is in the swapping area, then the BAZ subr
pointer has to point the a header routine to do the right
The Swapping area has a dispatch table at the head. Suppose the
routines are f1, f2, f3.
swap start address:
f1 --→ code1
f2 --→ code2
f3 --→ code3
(cond ((swapped-in 'f1))
(t (swap-in 'f2 (get-swap-specs))))
Then the subr pointers are:
f1 swap start
f2 swap start + 1
f3 swap start + 2
4. Maybe one should use least recently used?
5. How many routines should be resident?
6. Returns are hard! Suppose that you have:
(defun f1 (x)
... (computation (f2 ...)) ...)
and to get f2 you swap out f1! You have to be able to know you're in
F1 and to not swap it out, so you need several routines per swapping
7. Are these decisions automatic?
8. Calling out of a function in a swap area that might
cause that guy to be swapped out means that the
return route has to be smart too. So every function
call out of one that could do this means a call like:
(outcall 'function arg1 arg2 ...)
which might need to be coded for the right number of args
or else be a lexpr.
9. Each function swapped into the same area needs to
to be in a file with a call to some routine between